Vyatta VC5 Beta 3 GUI Phase I - Quickly Print Screening Through: Part 2

Using the GUI

In the first part, we’ve taken a quick look at the GUI.
Let’s now configure something using the GUI. Say add a NAT rule and a default route so that a host behind this Vyatta to access the Internet. And setup some firewall rules. Just to feel the GUI a little bit.

Adding a NAT rule

Vyatta said in their announce that the NAT rules area is to be improved over the time to provide a better way to manage and present the NAT rules.

Right now we are going to create a masquerade NAT rule on this Vyatta router’s external interface, to hide the internal subnet behind Vyatta.

From the Configuration tab, Navigation area, click the service node, click the nat sub-node, and click the Create button:

config_nat_1

Next click rule from the nat sub-node, enter a number for the NAT rule we are about to create in the Input/Output area, and click the Set button.

config_nat_2

And we are automatically taken to the next screen after we’ve clicked the Set button(this is the wizard feeling I was talking in part 1). In the Input/Output area, eth0(this is the external interface for this machine) will be the outbound-interface and the type will be masquerade(select it from the drop-down menu). Click the Set button.

config_nat_3

And the modifications were set:

config_nat_4

Next we need to specify the source network for this NAT rule which will be the IP subnet behind Vyatta(the subnet which we will hide behind Vyatta).
Click source from the rule 100 sub-node and click the Create button:

config_nat_5

Configure the needed subnet in the Input/Output area and click the Set button:

config_nat_6

And we’re done.
All we need to do now is to commit our configuration changes, so click the Commit button:

config_nat_7

The configuration is being applied:

config_nat_8

And now the configuration was successfully applied:

config_nat_9

View the current configuration by clicking the Show button:

config_nat_10

Now, say we’ve created more NAT rules and we want to modify some rules. Perhaps we want to change the number of a NAT rule. We can’t do that from the GUI(as we cannot do that from the CLI too):

config_nat_11

config_nat_12

However, as can be seen we can easily edit the settings of this NAT rule(like the source address):

config_nat_13

So be careful when numbering your NAT rules.

Also we cannot copy and paste an existing NAT rule to quickly modify it if we want to add a new similar NAT rule and speed the process a little bit.

 

Adding a static default route

From the Configuration tab, Navigation area, click the protocols node, click the static sub-node, and click the route sub-node. In the Input/Output area add the needed ipv4net, which is 0.0.0.0/0 and click the Set button.

config_st_route_1

The ipv4subnet was set for this route:

config_st_route_2

And now move to the next-hop sub-node.
From this node, the Input/Output area add the IP address of the next-hop router for this route, and click the Set button.

config_st_route_3

After the next-hop router for this route was set, we can Commit our configuration:

config_st_route_4

Our configuration was applied:

config_st_route_5

config_st_route_6

Now a host behind this Vyatta router should be able to access the Internet(we can do a quick test). And we can monitor our NAT rule from the Operation tab as we saw in part 1.

 

Saving the configuration

We’ve committed our configuration changes, but if we reboot now the Vyatta router, our changes will be lost.

So we need to save them.
This is a very easy process.

From the Configuration tab, the Command Buttons Area, click the Save button:

save_1

The command is being processed:

save_2

And we are prompted to specify a configuration file. The default one is config.boot, this configuration file will be loaded at boot. It’s fine for us, so click OK:

save_3

And our configuration was successfully saved:

save_4

As you have seen, we cannot save the configuration file on our management machine with the Save button. Neither we can load a configuration file from our management machine with the Load command:

load

 

Add some firewall rules

As with NAT rules, Vyatta said in their announce that the firewall rules area is to be improved over the time to provide a better way to manage and present the firewall rules.

Say now we want to secure the external interface of this Vyatta machine , which is eth0.

With Vyatta we can apply to an interface firewall instances as: in, out and local.

Since we are talking about Vyatta itself now and its external interface eth0, we are going to use a local firewall instance on eth0.
When applying as local a firewall instance, the firewall will filter packets destined for the Vyatta system itself, as shown bellow:

Firewall_Instances

As you will see, we currently cannot work with firewall objects to simplify management, say to create an object for a DNS server or NTP server, or an object for the internal network, and re-use them within our firewall rules.

First we are going to create a firewall instance, add a few rules to it, then apply this firewall instance as local on the eth0 interface.

So basically we want the router not to respond to ping from the external network, drop any SYN segments that might be used to scan the external interface for open ports etc.

We must be careful with a few things. For example, ping might be used for testing connectivity from the router itself, or the router uses NTP and as an NTP server an external host, or the router needs to resolve a DNS name thus will use DNS to query an external DNS server, or the router may need access to updates(HTTP). Also if you enable the web proxy service on the router you need to allow returning HTTP and HTTPS traffic. Before apply a local firewall instance on an interface, make sure you know what traffic is involved, in order not to block legitimate traffic.
Right now the GUI can be accessed from the external network, when we will finish setting up our firewall rules, the GUI will no longer be accessible from the external network. Of course, if we want this to be possible, we can easily add a firewall rule to allow this, or maybe shrink this firewall rule so just a few external hosts to be allowed to manage this Vyatta using the GUI.

So, for example, due to the nature of the local firewall instance, the echo-requests packets from the router itself to an external destination will be allowed, but echo-replies messages for these packets will be denied. So if we want to be able to ping from the router itself, we need to permit the returning echo-replies messages for the sent echo-requests messages. In a similar way we need to allow NTP, DNS etc. if the connections originate from the router itself.

Let’s create a firewall rule to permit the returning echo-replies messages for the sent echo-requests messages by the router itself.

First thing to do is to create the firewall node:

From the Configuration tab, Navigation area, click the firewall node, and click the Create button:

cr_fw_1'

These default settings are fine for us now:

cr_fw_1''

Next we need to create the firewall instance we are going to apply as local on the external interface(eth0).
So click the name sub-node. In the Input/Output area add a name for this firewall instance, say Localeth0, and click the Set button.

cr_fw_1

After hitting the Set button, we’re taken automatically to another screen, to set a description for this firewall instance(optional, if we want to):

cr_fw_2

I don’t want to enter a description for this firewall instance right now, so I’ve clicked the rule sub-node to add a firewall rule within this firewall instance, the rule to permit the returning echo-replies messages for the echo-requests messages sent by the router itself. Specified a number for this rule, and click the Set button.

cr_fw_3

And we’re taken automatically to the rule 100’s properties. Set the action to accept(select it from the drop-down menu) and the protocol to icmp. Click the Set button.

cr_fw_4

Our settings were set:

cr_fw_5 

Navigate to the destination sub-node of this rule, and click the Create button:

cr_fw_6

Now specify the local IP address of the external interface, and click the Set button:

cr_fw_7

The specified destination was set:

cr_fw_8

Next click the icmp sub-node of the rule 100, and click the Create button:

cr_fw_9

We’re taken automatically to the next screen, where we are going to enter the ICMP code and type corresponding to the ICMP echo-reply message. Click the Set button:

cr_fw_10

And nothing happens…

A quick work around that I found: set the ICMP code and type to something different than 0, say 1 and 1:

cr_fw_10'

And then set ICMP code and type to 0 and 0 and click the Set button: now the changes are being applied:

cr_fw_10''

cr_fw_10'''

Next move to the state sub-node of the rule 100, and click the Create button:

cr_fw_11

In the screen that appears, check the established and related checkboxes, as the router expects echo-replies messages only for the echo-requests messages sent by it, and click the Set button:

cr_fw_12

And now, Commit the changes:

cr_fw_13

The configuration was applied:

cr_fw_14

cr_fw_15

cr_fw_16

OK. Let’s add a firewall rule allowing NTP now. I’m going to show only the relevant parts this time.

First thing to do, is to check the IP address of the configured NTP server.
We can quickly do that by using the Show command button(which displays the entire configuration of this router) from the Configuration tab:

cr_fw_17

And additionally we can take at the output produced by the show ntp command in the Operation tab:

cr_fw_18

Now we know the IP address of the configured NTP server, so we can go to the Configuration tab, Navigation area, expand the firewall node, expand the name sub-node, expand the created Localeth0 sub-node and click on the rule sub-node. Enter a number for this rule to be added, and click the Set button:

cr_fw_20

And we’re taken automatically to the rule 110’s properties. Set the action to accept(from the drop-down menu) and the protocol to udp(NTP uses UDP). Click the Set button.

cr_fw_21

Our settings were set:

cr_fw_22

I’ve added as the destination for this rule the local IP address from the external interface eth0:

cr_fw_23

And this time we’re going to add also a source, so click the source sub-node, and click the Create button:

cr_fw_24

In the Input/Output area add the IP address of the NTP server. Also, the replies packets from the NTP server will be sourced from UDP port 123(the NTP server listens for connections on UDP port 123), so we will add this port as the source port in the Input/Output area. Click the Set button.

cr_fw_25

cr_fw_26

I’ve added a state too, checked the established and related checkboxes, as the router expects replies messages only for the UDP messages sent by it to the NTP server. Then hit the Commit button.

cr_fw_27

The configuration was applied:

cr_fw_28

cr_fw_29

So we’re done with the NTP rule.

In a similar fashion, as UDP is used too, we’re going to add a rule to allow the router to resolve DNS names by using the configured external DNS server.
I’ve added rule 120, which it’s exactly the same as rule 110, except the source node, which is different, the source address is the address of the external DNS server and the source port is 53:

cr_fw_30

cr_fw_31

Also note that rule 120 will apply if we use DNS forwarding on Vyatta for the hosts behind Vyatta located on the internal network:

cr_fw_50

OK. So we’ve added enough firewall rules for now.

It’s time to apply the created firewall instance Localeth0 as local on the interface eth0.

From the Configuration tab, Navigation area, expand the interfaces node, ethernet sub-node, eth0 sub-node, firewall sub-node and click the local sub-node. Click the Create button:

cr_fw_33

And in the screen that appears, Input/Output area, manually type the name of the firewall instance we want to add. As can be seen, we cannot select the firewall instance we want(I’ve tried to drag the one created, just for fun, in this box but it didn’t work). Click the Set button.

cr_fw_34

And time to Commit our configuration:

cr_fw_35

And our configuration was successfully committed, the firewall now starts to filter the specified traffic:

cr_fw_36

cr_fw_37

Let’s try to ping a host using its DNS name from this router.
Move into the Operation tab, ping node, and run a ping command:

cr_fw_38

Success.

A quick nmap scan for the external interface eth0 of this router:

nmap

From the Operation tab, show node, firewall sub-node, we can display various info about our firewall instance and firewall rules:

cr_fw_40

cr_fw_39

cr_fw_41

Say I’ve enabled the webproxy service, and the web proxy listens for connections on the IP address of the internal interface eth0, port 8080:

cr_fw_47

Our current firewall rules from the Localeth0 firewall instance block the proxied web traffic.

So I’ve added a new firewall rule to the Localeth0 firewall instance, rule 130, to allow this web traffic:

cr_fw_48

cr_fw_45

Although the hints don’t tell us this aspect, we can add multiple ports if we want to, see the documentation for more details:

cr_fw_44

cr_fw_46

cr_fw_42

cr_fw_43

cr_fw_49

As with the NAT rules, be careful with the numbering of the firewall rules, as you cannot change the number of a firewall rule later.
However we can easily edit the settings of a firewall rule, like source/destination addresses, source/destination ports etc.

 

Saving the configuration

As we did before, don’t forget to save the configuration, otherwise a reboot will erase any settings unsaved:

cr_fw_51

cr_fw_52

Comments (4) -

  • stig

    3/5/2009 9:23:51 PM |

    Adrian, Thanks for taking the time to do this.  I saw your comment about not being able to load a remote file, so I opened a bug (http://bugzilla.vyatta.com/show_bug.cgi?id=4177).  Feel free to open other bugs you have found or enhancement requests.

  • adimcev

    3/6/2009 12:05:30 AM |

    Hi Stig,
    Thanks!
    Adrian

  • Kevin Choi

    7/15/2009 12:35:15 AM |

    Adrian,

    Excellent job! Thank you. BTW, I am the Godfather of this GUI. The next GUI version will be much betterLaughing

    Kevin

    • adimcev

      7/15/2009 8:31:15 AM |

      Hi Kevin,

      Looking forward to see the new GUI. Smile

      Thanks,
      Adrian

Comments are closed