Download Vyatta

[Stella Kreuter]

Im looking to add some vyatta devices to our ISE environment for TACACS+ authentication. I'm running in to issues getting the correct Attributes sent to the device. By default, the vyatta dumps you in to "tacplus-operator" role when authenticating with a tacacs server. On our old deployment (linux using tac_plus), we have the following options listed for our vyattas, which tell it to use "tacplus-admin" for our users:

Thanks for the response. I am actually pasting all that in to the "raw" section. I've tried different combinations with curly brackets, without, with quotes, without etc. I even tried the "level = admin", same result. It seems as if anything I put in there isn't actually being used on the vyatta side, or more likely, I'm not putting it in there the way it expects it.

By default, TACACS+ authorized users on the Brocade vRouter are given operator-level access. However, you can specify the authentication level for individual TACACS+ authorized users on the local Brocade vRouter. Like the mapping of user IDs, thiscon guration is speci ed on the TACACS+ server, as shown in the following example:

Logging in to the local Brocade vRouter as the administrator user in this instance provides administrative-level access. You can alsocon gure an additional level on the TACACS+ server as superuser to provide superuser-level access.

We want the lab subnet (192.168.50.0/24) to be able to reach the client subnet (192.168.70.0/24) so it has Internet access, but not the production server subnet (192.168.60.0/24). We want the production server subnet to be able to reach the client subnet, again for Internet access, but not the lab subnet. We want the client subnet to be able to reach both the lab and the production server subnet. In addition, we want a specific IP address to be able to manage Vyatta from the client subnet, but no others.

Tip: When there are no matching rules, traffic is rejected. With this in mind, you could even set up a simple dummy rule that blocks port 80 traffic, ie. http traffic. With this rule in place, all other traffic on that that hits that firewall would be blocked as well. You would simply change rule 1000 for eth0LocalFilter source to:

The rules for the production networks routing would be very similar to the rules above, as well as configuring rules from the client subnet to the other subnets. You can configure rules as you need them to allow traffic from one place to the other.

Vyatta can be run in a virtual machine, can be downloaded as a VMware Workstation virtual appliance and then imported into ESX, can run directly on a multitude of hardware, and can even run directly from CD, without installing on a hard drive (though this configuration obviously does not allow you to save changes that you make in the router software.)

[setdeleteshow] firewall name name rule rule-num action [acceptrejectdrop]

[setdeleteshow] firewall name name rule rule-num source [address addressport portmac-address mac-addr]

[setdeleteshow] firewall name name rule rule-num destination [address addressport portmac-address mac-addr]

[setshow] interfaces ethernet ethX firewall [inoutlocal] name

I will let you know how it goes as soon as I tested it out.

Also I entered the vyatta eth1 WAN address in the router and the VPN port just like I did for the RDP. I remembered that the router itself has a firewall and will block the VPN connection from coming in like what it use to do with the RDP connection. Whats your opinion on that?

Guess what. As soon as I create the local firewall on eth1 WAN interface all the computers in the lab stop browsing the internet. I try it on the local interface eth0 and its same result, the internet stops routing to the machines in the lab and it kicked me off the ssh and GUI. I had to connect back to the original host pc and delete it.

What am I doing wrong?

I have observed your vpn firewall configuration and another person own and I noticed that in both of them there were not destination address in the firewall rule just the destination port alone. Should I remove the destination address? I used my WAN IP for the destination address.

If that works, then create a new firewall ruleset and title it something like, WAN_IN_TO_ROUTER, and add the firewall rule to it that allows VPN. I believe the problem is that you are using the IN firewall when you need to open the port on the LOCAL firewall.

I would guess that what happened when you added the local firewall to eth1, it started blocking response packets that are coming back from the browser sessions. Can you try adding the VPN rule to the WAN_IN firewall and applying that firewall to both the IN and LOCAL channels?

Thats what I did the first time before I created another VPN rule. It was the originally WAN_IN firewall I was using for the VPN rule and I applied it to the local firewall and thats where I noticed that it blocks the internet. I even just did it a while ago and its the same ting. I even completely remove all the firewall from the eth1 interface and its the same thing. I also even disable the firewall from the router and its the same thing. I am wondering if you need a destination address in the firewall rule and which IP address should be used, the WAN IP or the internal server IP.

Anyways, thank you for all your help which you have given me over the past few weeks. I will always be grateful.

@Jason: My pleasure on trying to help you work it out. The only other thing I can think of doing, is having you post you whole configuration and loading it in my lab and troubleshooting it from there. Let me know if you want me to do that, otherwise, good luck.

I am using vyatta and using some nat rule which are working absolutely fine.But when i configure firewall it gets configured easily but when i need to implement the firewall on nic for the incoming traffic(making in rule) to lan machine.It stops working.I am pasting the config.please suggest the optimal solution

@Adam: What information do you have about the person that is using your Internet? Same IP address used every time? Mac address? etc.? Also, is your firewall currently configured (in, out, local)? Are you using Vyatta as a router/gateway or pure router?

For CompB, you need a rule that allows established (or it might be called well-established) communication back across the router to CompA. That means that CompA can initiate a connection to CompB and the router will allow CompB to respond, since CompA started it, but will not let CompB initiate anything.

Another way to handle it could be by using NAT. Then the router would be the gatekeeper and only shell all responses back to the requester, and compB would not be able to initiate anything because it would only see the router.

My name is Clement DeLarge and I'm a Staff Consultant at VMware. When I'm not working, I'm spending time with family, riding my motorcycle, playing games, playing with technology, or just about anything else that's fun that I come across. The views and opinions I expressed are those of my own and do not necessarily reflect the official policy or position of VMware, unless otherwise stated.

Oxidized is pulling my Juniper configs just fine, but having two issues. First issue is , pulling the Arista configs and issue is i think its not pulling the vyatta confgs due to the ssh port needing to be 2000.

Below is my Oxidized config. On the GUI when the config download starts it just shows the Vyatta/Juniper devices and no Airsta devices. Please help.

One thing to note was that it was useful to add one vNIC at a time to the Vyatta VM. This way, as I add a vNIC, it gets labeled in VMware Workstation sequentially, as in: Network Adapter, Network Adapter 2, Network Adapter 3, etc., and Vyatta then installs them sequentially as eth0, eth1, eth2, etc. I made the mistake of adding four network adapters at one time and then booting the appliance. I assigned IPs and configured the router as I wanted, then was troubleshooting for hours until I realized that Vyatta had simply assigned the adapters as it found them at boot time which was not necessarily the order in which they were installed or labeled in the VM itself. So, save yourself some headaches and add one vNIC at a time with reboots in between.

Can you 192.168.1.x ip addresses ping any of your 10.x.x.x addresses, including the 10.x.x.x. addresses on vyatta itself? Bascially, can devices coming through your wireless network ping the 10.x.x.x addresses?

My conifig is slightly different than yours. I also enabled routing for a bit on my Win7 laptop so I could a route pointing to the 172.16.x.x networks via the vyatta 192.168.41.x interface. If it works outboud though, the routing should be in place. This is driving me nuts..:)

which sends/receives 802.1Q tagged packets. An in that case how would we configure an interface in vyatta to be used as trunk? And use that trunk to carry tagged information packets of all three VLANs to other end (in your case the Cisco 2960)?

3a8082e126