Posts Tagged ‘vpn’

Vyatta to DD-WRT: OpenVPN Site to Site

Sunday, July 17th, 2011

I recently changed my site-to-site VPN configuration.  Previously, I had been running my remote OpenVPN endpoints on CentOS with Quagga and OpenVPN installed.  Now that I have a couple Vyatta VM’s routing traffic on the internal network I’ve been wanting to use those as the VPN endpoints.  This simplifies things a big, and lets me remove Quagga from the two CentOS boxes.  I’ve also been wanting to switch my OpenVPN to bridge mode as opposed to routed mode.  OpenVPN doesn’t currently support IPv6.  Using bridge mode allows me to configure the L3 aspects outside of OpenVPN.

Rather than bridged the OpenVPN interface directly to one of the VLAN’s on each end of the tunnel (which would result in broadcasts traversing the WAN, and hosts on both locations being on the same Layer 3 network, not desirable in this case) I’m not actually “bridging” the VPN tunnel interfaces to other interfaces.  Instead, I created a bridge interface on each end of the connection with only the OpenVPN tunnel interface included in it.  I assigned the IP addresses on the bridge interfaces.  Here’s a diagram on how the interfaces are set up:

diagram2

I hadn’t used OpenVPN on Vyatta before, or OpenVPN in bridged mode, so this was a little new for me.  I generated a static key and copied it to all of the devices.  I have the OSPF costs on my internal Vyatta routers set so that one is always preferred.  (I also have that router preferred in VRRP, though this is unrelated to OpenVPN).  The Vyatta VM’s aren’t directly connected to the Internet, so I have OpenVPN listening on an internal address instead.  That internal address is then NAT’ed to a public IP on my edge router.  Ignoring the edge router, here’s a simplified diagram of the tunnels:

diagram1

Here is the configuration I used on the two Vyatta endpoints.  The only OpenVPN feature I’m using that Vyatta doesn’t have a configuration option for is the compression.  Thankfully, Vyatta let’s you manually specify OpenVPN configuration that they don’t support with “openvpn-option”.

intra-rtr-1:

bridge br0 {
        address 172.16.5.1/30
        description "L3 IF for APT site to site VPN"
        hello-time 2
        ip {
            ospf {
                authentication {
                    md5 {
                        key-id 1 {
                            md5-key myospfkey
                        }
                    }
                }
                cost 51
                dead-interval 40
                hello-interval 10
                priority 1
                retransmit-interval 5
                transmit-delay 1
            }
        }
        max-age 20
        priority 0
        stp false
    }
openvpn vtun0 {
        bridge-group {
            bridge br0
        }
        local-host 192.168.1.21
        local-port 1501
        mode site-to-site
        openvpn-option --comp-lzo
        protocol udp
        shared-secret-key-file /root/apt-rtr.secret
    }

intra-rtr-2:

 bridge br0 {
        address 172.16.6.1/30
        description "L3 IF for APT site to site VPN"
        hello-time 2
        ip {
            ospf {
                authentication {
                    md5 {
                        key-id 1 {
                            md5-key myospfkey
                        }
                    }
                }
                cost 49
                dead-interval 40
                hello-interval 10
                priority 1
                retransmit-interval 5
                transmit-delay 1
            }
        }
        max-age 20
        priority 0
        stp false
    }
 openvpn vtun0 {
        bridge-group {
            bridge br0
        }
        local-host 192.168.1.22
        local-port 1502
        mode site-to-site
        openvpn-option --comp-lzo
        protocol udp
        shared-secret-key-file /root/apt-rtr.secret
    }

I’m still using DD-WRT on the endpoint in my apartment. I’ll soon be switching this over to Vyatta as well, but until then I’m relying on some somewhat messy methods of using OpenVPN. I don’t trust the OpenVPN setup that the DD-WRT web GUI uses (for one, they use NAT’ing in the site-to-site connection…which makes no sense whatsoever), so I have a shell script on an attached flash drive that runs on the OpenVPN daemons. The included version of Quagga also does not work on DD-WRT (apparently they compiled it wrong), so I had to find an old statically compiled version. That’s what I’m using for OSPF on the DD-WRT box right now. For this new VPN setup, I just added a few lines to the shell script I already use for OpenVPN.

Anyway, here is the OpenVPN config on my DD-WRT router. It’s fairly simple. I actually have two separate OpenVPN daemons on the DD-WRT system. One that connects to each of my two internal Vyatta routers. The only thing different between them is the port that they connect to.

dev tap0
proto udp
remote my.vpn.endpoint 1501
resolv-retry infinite
nobind
secret intra-rtr.secret
comp-lzo

Here is the script I’m using on the DD-WRT router. It creates the bridge interfaces, and adds the OpenVPN interfaces to the bridge groups. It also assigns the IP’s on the bridge interfaces, starts Quagga, and starts the OpenVPN daemons. When starting the OpenVPN daemons, it also calls DD-WRT’s route down script, to make sure the NAT’ing that DD-WRT tries to do by default is removed from iptables.

openvpn --mktun --dev tap0
openvpn --mktun --dev tap1
brctl addbr br10
brctl addif br10 tap0
brctl addbr br11
brctl addif br11 tap1
ifconfig tap0 up
ifconfig tap1 up

ifconfig br10 172.16.5.2 netmask 255.255.255.252
ifconfig br10 promisc
ifconfig br10 up
ifconfig br11 172.16.6.2 netmask 255.255.255.252
ifconfig br11 promisc
ifconfig br11 up

zebra --daemon --config_file /jffs/opt/zebra.conf
ospfd --daemon --config_file /jffs/opt/ospfd.conf

( sleep 2 ; killall openvpn ; /tmp/openvpncl/route-down.sh ;
    /jffs/opt/ovpn --config /jffs/opt/openvpn-intra-rtr-1.conf --daemon) &
( sleep 3 ; killall openvpn ; /tmp/openvpncl/route-down.sh ;
   /jffs/opt/ovpn --config /jffs/opt/openvpn-intra-rtr-2.conf --daemon) &



Here’s the relevant OSPF configuration in Quagga on my DD-WRT router. Most of it’s fairly straightforward:

interface br10
 description L3 IF for site to site VPN - intra-rtr-1
 ip ospf authentication message-digest
 ip ospf message-digest-key 1 md5 myospfkey
 ip ospf cost 51
!
interface br11
 description L3 IF for site to site VPN - intra-rtr-2
 ip ospf authentication message-digest
 ip ospf message-digest-key 1 md5 myospfkey
 ip ospf cost 49
router ospf
 ospf router-id 192.168.17.1
 network 192.168.5.0/24 area 0.0.0.0
 network 192.168.6.0/24 area 0.0.0.0
 network 192.168.16.0/21 area 0.0.0.0
 area 0.0.0.0 authentication message-digest

I haven’t fully set up IPv6 yet. I’m planning on waiting until I replace my DD-WRT router with Vyatta to set all of that up. The version of Quagga I found that would run on DD-WRT doesn’t support OSPFv3. Vyatta does though.

Site to Site VPN with DLink Routers

Friday, June 4th, 2010

One of the satellite clinics here in Lilongwe has enough users that it really should be connected to our main site with a site to site VPN.  People are wanting to use Outlook for email, we need to be able to push out group policies, people should be able to log on to the Active Directory domain, etc.  We had a client-server based VPN (OpenVPN), but it’s not easily possible to login to AD or apply group policies.  Things would just be a lot simpler if there was connectivity between the LAN’s at both locations.

This was done in the past through another ISP here.  It sort of worked, but they were extremely expensive.  Unfortunately, instead of having quality hardware, we have several cheap DLink VPN routers.  We probably would have had a lot fewer issues if they simply had Cisco routers or a Linux box at the remote site that we could use OpenVPN with, but unfortunately that’s not the case.

image

We were eventually able get them connected, though there seems to be no way to control what traffic it routes over the tunnel.  With a Cisco site-to-site VPN, an access list could be used to control which traffic is tunneled and which traffic is not.  The former service provider used a proxy to get around this and send all web traffic through our Internet connection, but man is that a ugly solution.  Also, both the dynamic routing (with RIP) and SNMP monitoring “features” of these devices appear to do nothing at all.

Right now we’re having problems with traffic between the sites.  ICMP works, but HTTP generally doesn’t.  OpenVPN worked fine.

Right now, I think our problems are related to the MTU (maximum transmission unit), the maximum size of packet that a device can handle.  Most 100 Mbps Ethernet equipment supports MTU’s of around 1500 bytes.  This can frequently be a problem with VPN’s, because the VPN endpoints encapsulate the original packets inside of IPSec/GRE/OpenVPN/etc. packet.  For an example, let’s assume that the MTU for path the VPN tunnel is traveling between its endpoints is 1500 bytes, and the overhead from the VPN is 50 bytes.  If computer A sends a packet that’s 1480 bytes, and the VPN endpoint X encapsulates it, the resulting packet is over 1500 bytes.  This means that the MTU for traffic going through the tunnel is less than the typical MTU because of the overhead caused by the VPN connection.

image

This can cause difficult to troubleshoot problems with a VPN tunnel, because some traffic, like normal pings/ICMP, that is well under the MTU will pass through the tunnel just fine, but larger packets can’t “fit” in the VPN tunnel.

Another interesting note however is that the DLink router works when its at another location, meaning that it could be related to the ISP’s configuration. 

Tanzania Projects

Tuesday, June 1st, 2010

Wow, had a really busy four or five days in Moshi, Tanzania.  Wish I would have had more time to relax and sight see, it usually ended up being 12 hour days for us.  We got a lot down, though we ran in to a lot of issues that slowed us down.

The major projects we worked on while we were in Tanzania were setting up a new VSAT Internet connection, installing a remote access system, installing a network monitoring system, managing the bandwidth utilization, as well as connecting group of data computers here to the rest of the network.

For the VSAT connection, I was responsible for modifying the Cisco router configuration to work with the new connection.  It was mostly a matter of adding NAT entries, changing a couple IP addresses, and adding a new default route.  We also helped a satellite technician with aligning the satellite dish and configuring the primary and backup satellite modems.  That turned out to be the more challenging aspect.  Almost all of our first day here was spent working on that.  One of the biggest issues we ran in to was a mis-understanding between our service provider and the satellite installer/technician.  The technician thought the angle he was given was the angle of elevation for the satellite dish, however it was apparently the angle of the beam as it hits the ground, which doesn’t take some factors in to consideration.  The satellite modems we received were also tricky to install.  Some of the settings we had to set could only be accessed in in particular mode, and switching between modes required a arduously slow reboot.  Unfortunately, there is no way of simply copying a configuration file over to these modems, it all had to be done manually, going through a clunky menu-based null modem cable connection.

For the remote access, we ended up going with Windows Server PPTP VPN.  I tried to configure the Cisco Easy VPN and Cisco WebVPN, though I wasn’t able to get them to work with the limited about of time we had here. So instead we looked at the Windows Server VPN.  While it isn’t very customizable, it was much easier to get working than I thought it would be.

If we would have had a Linux machine available at that time, I would have chosen OpenVPN.  That’s what I configured at the project in Malawi, that’s what I use at home.  The day after doing the VPN, we did end up installing Linux to use on a server here to work as a transparent web proxy for Squid.  On our Cisco gateway router, I used a route map to forward port 80 traffic through our Linux squid machine.  This is the first time I’ve actually used Squid in this fashion, seems to work fairly well once I was able to work out a few kink in the configuration.  Because of the limited bandwidth, we’re limiting the maximum download or upload size to 20 MB.  There is a separate static IP set aside for cases where someone has to be allowed through the proxy.  (It’s just another line on the Cisco ACL that chooses traffic to send through the proxy.)  I wish there was a way to automatically disable the route map if the proxy machine was down though, that would make me more comfortable with this setup.  I’ll try to post the configurations for some of this later when I have more time, I’m at an internet cafe in Nairobi now.

Update:

Here are the pertinent parts of the Squid configuration.

acl lan src 1.2.3.0/24

# Block some websites all the time
acl always_block url_regex -i "/etc/squid/always_block.txt"
http_access deny always_block
deny_info
http://1.2.3.4:8080/blocked.html always_block

acl work_hours time MTWHF 08:00-17:00

# Block some websites only during work hours
acl workhours_block url_regex -i "/etc/squid/workhours_block.txt"
http_access deny workhours_block work_hours
deny_info
http://1.2.3.4:8080/blocked.html workhours_block work_hours

# Block Malware
acl malware_block url_regex -i "/etc/squid/malware_block.txt"
http_access deny malware_block
deny_info
http://1.2.3.4:8080/malware.html malware_block

# limit downloads to 20 MB, uploads to 20 MB
reply_body_max_size 20000000 allow lan
request_body_max_size 20 MB

http_access allow lan
http_access deny all
http_reply_access allow all

http_port 3129 transparent

And here’s the configuration on the router, that forces all the web traffic to go through the proxy (except for traffic from a few servers).  Fa1 is the inside LAN interface.

int fa1
     ip policy route-map WebFilterProxy

ip access-list extended WebFilterHosts
deny   tcp any any neq www
deny   tcp host 1.2.3.6 any
deny   tcp host 1.2.3.5 any
deny   tcp host 1.2.3.4 any
deny   tcp host 1.2.3.3 any
permit tcp any any

route-map WebFilterProxy permit 5
match ip address WebFilterHosts
set ip next-hop 1.2.3.4

Connection to Tonse

Sunday, May 23rd, 2010

On Thursday evening we finally were able to get connected to Tonse.  We needed a public IP address so that people at the site in Area 18 an connect to our OpenVPN server.  It was a long, tiring, journey to get that to work.  At first, their modem / customer premise equipment (which is made by Greenpacket) was using NAT and acting as a router.image

This complicated things, because our Cisco router also does NAT for  our internal addresses, 10.10.13.10.  We were originally attempting to use a DMZ setup, where the Tonse modem did NAT, but the outside IP of our Cisco router was in a DMZ so all traffic would go to it.  This didn’t seem to actually work.  To try to see where the problem was, we put a switch in between our Cisco router and the Tonse modem.  When we opened the ports for OpenVPN on our Cisco router we were able to access it from the switch in between the modem and the router.  However, even when putting the Cisco router in the DMZ for the Tonse modem, we weren’t able to access the VPN from outside of the Tonse modem.

Eventually we were able to enabled bridging mode on Tonse’s modem, so our Cisco router directly had a public 41.x.y.z IP address.  This would make it much easier for the users at Area 18 to access our VPN server.  NAT is only being done once.

image

There was still one caveat though.  The router wasn’t routing the VPN traffic back out the interface to Tonse.  I connected my laptop to the Tonse connection, and strangely enough, the default gateway my laptop received was not on the same subnet as the laptop itself.  My laptop received an IP address on a 41.x.y.z subnet, however, the default gateway was a private 10.a.b.c IP.  That still does not make much sense to me, but apparently it works.  The router wasn’t able to get to ping that IP address.  So I ended up adding a static route on the Cisco router, telling it to send traffic to the 10.a.b.c IP address through the Tonse interface.  This allowed everything to work.

I also moved the OpenVPN service from our primary mail server to the backup mail server.  At first it didn’t work, which was frustrating, as the configuration was identical.  Then I realized that that I forgot to enable IP forwarding on the Linux server.  After fixing that, it worked fine.

Michael went to Area 18 the next day, and they were able to connect to the VPN.  It seemed to be a fair amount faster than it was when the connection was going through the Ariave satellite link.    The latency from Michael’s house (also on Tonse, but on a different tower) seems to be greater than it is from Area 18.

First Impressions of Malawi

Tuesday, May 18th, 2010

I’ve been in Malawi now since Sunday afternoon.  So far I’ve just been in Lilongwe, this weekend we might travel elsewhere.  I have a pre-paid mobile phone on the Zain network here.  The balance of the account is measured in “units”, a text message is 10 units, I’m not sure about voice calls yet.  I’ve been told that 160 units costs about $1.  Its interesting, some people here also pre-pay for things like electricity – you pay for a set number of “units”, that correspond to the amount of electricity you are able to use.  The local currency, kwacha’s, are exchanged at about 180 kwacha’s for 1 USD.  500 kwacha bills are the most common, resulting in my wallet feeling larger than before :)

IT-wise, there are a lot of challenges.  So far we’ve spent some time looking at a VPN connection that I set up earlier.  While the site the user is connecting in from is only a few miles away from the central hospital, the connection still must go through the satellite link because that is the only Internet connection Tidziwe has.  This makes their lab application extremely slow, because of the latency and because the VPN traffic has to compete with so much other traffic over the limited satellite connection.  It appears to be difficult to do our own wireless point to point connection in this case, because of the landscape not permitting line-of-sight.  The remote site, in Area 18* here in Lilongwe, is connected via a new WiMax provider here in Malawi, Tonse.  Both Tidziwe and the Area 18 site have line-of-sight to one of the towers that Tonse uses, so we are hoping to get Tidziwe connected to Tonse, to allow Area 18 to have a fast (in terms of latency, because it won’t be using the satellite connection) and relatively high bandwidth (because the traffic will just be traversing Tonse’s internal network, it should provide faster speeds than traffic going across the Internet) connection.  Then we can run the VPN software (OpenVPN) to connect in to the internal network in Tidiziwe and allow the lab users to access their application.

For the past several months, the UNC Project has also been using a Barracuda web filtering device to minimize the bandwidth wasted from people browsing to Facebook, YouTube, etc.  The servers are on the WAN side of the Barracuda appliance.  I need to research to see if this is a recommended best practice or not.  Interestingly enough there seems to be some connectivity issues between the end-user desktop/notebooks, and the servers ( as well as the Cisco router).  Group policy updates aren’t applying, some clients are having difficulties updating from the Symantec server, and I couldn’t SSH into the router from behind the Barracuda.  We’re not sure that its the appliance causing the problem, it could also be something on the Cisco router – the servers and Barracuda are connected to different ports.  (Though the two ports are part of a bridged virtual interface / on the same VLAN / etc, so I’m thinking the router shouldn’t be involved in anything other than just doing L2 switching).

Today, we also looked at a multipoint wireless connection that connects several buildings that the UNC Project at the Kamuzu Central Hospital.  It was somewhat hard to understand at first – while the connection what previously working, routes were not set up on the main router to allow us to connect to intermediate devices.  The access points at the other buildings also appear to be using NAT, which doesn’t make sense – its not necessary at all in this instances, and actually makes the network harder to manage.  There are a few other things with the network setup that don’t make sense to me.  For instance, before using Tonse, they used another ISP here, that used a site-to-site VPN between Tidziwe and Area 18, but instead of setting up the routes to send all the appropriate traffic through the site-to-site tunnel, they set up a proxy server at the main Tidiziwe site, and set the clients to use that at the remote site.  To me, that just seems like an ugly, awkward solution.  I’m not sure if I’m just not seeing the rationale for these type of setups yet, or if they truly just don’t make sense

It’s difficult to purchase hardware here, it all has to be shipped in from another country.  South Africa is the closest country with a large technology base.  There are also some cultural differences in the workplace regarding employees and their managers.  I’ve also noticed that people shake hands differently here.  Instead of a firm grip and a quick shake up and down, its a much looser grip for longer, without as much movement.  I had read that people did this differently across the world, but it’s kind of neat to actually consistently notice it.

Today we discussed an opportunity in Tanzania that may result in a four day trip to Moshi, near Mt. Kilimanjaro, at the end of the month.  More details about this will be forthcoming.

*Neighborhoods in Lilongwe are called areas and have a number.

Projects

Friday, May 14th, 2010

Now for the promised explanation of what I’ll be doing over in Africa.  My friend Michael works for UNC at the Tidziwe hospital in Malawi.  They currently are using AtMail for their mail services – Michael and I helped set this up after they bought it about a year ago.  I’ll hopefully be setting up an Exchange 2010 server to act as a pilot to see if they want to deploy it further.

They also want to use Windows Sharepoint Services (Sharepoint Foundation in the 2010 version) for internal collaboration and document sharing.  I’ll help them install and configure this as well.  The 2010 version was just released, I haven’t had a chance to play around with it yet.  The hardware requirements on the server end might make it somewhat more difficult for them to deploy though.  I’m thinking I’ll probably recommend using Windows Sharepoint Services 3, which is more more established.

The UNC project in Malawi is also in need of having a solid backup system put into place.  I’m going to evaluate the applications and data they use and help them implement a basic system to backup their data in case of problems.  One issue that appears to be fairly common there is a loss of electricity.  Lastly, I might help segment their network into VLAN’s to give them a little bit better control over the traffic flowing through their limited Internet connection.  They already have a Barracuda web filtering device that the purchased last year, so this will help enhance the power of their filtering appliance.

Now, I’m also hoping to work on a few other projects that I think could benefit them. 

They have been trying to establish site to site links between satellite clinics around Lilongwe and the main facility.  Some of these links were point-to-point wifi solutions, and some of them are thought to be more appropriate for a site to site VPN.  Both of those topics interest me, and I’m hoping I’ll be able to get the sites connected together. 

A network access control system could also benefit them, though the hassle may outweigh the benefit.  It sounds as if they have problems with a lot of people bringing unauthorized and/or insecure devices on to the network.  A NAC system can help to keep those users off the network, or at least on a different VLAN.

So there’s the major things I want to focus on in Malawi.  Also, I’ll probably be spending a few days in Moshi, Tanzania.  It’s a Duke University medical clinic near Mt. Kilimanjaro that has to switch satellite ISP’s in the next month.  Michael and I are planning on traveling there to assist them with the transition, and to provide additional network advice and suggestions in the future.  It’ll probably be around the end of the month – May 29 – June 1, but I’m not 100% sure yet.

Copyright 2009 Simpliciti Solutions