OPenVPN Routing to ENTIRE network.
-
its best to start by drawing up a schematic of your network. with included devices/ip/ssubnets/routes/..
that way it makes a lot more sense and will be easier to provide you with a solution
-
Let me work out a diagram.
-
Just guessing but your working site to site routing is by lan address. Did you add routing for vpn server address?
For example site 2 will need a route back to RoadWarrior VPN gateway.
-
Sorry found an error in my diagram….
-
Yes, I have the following in my Road Warrior Server Advanced Configuration:
push "route 192.168.0.0 255.255.255.0"; push "route 192.168.10.0 255.255.255.0";push "route 192.168.40.0 255.255.255.0"
Each site to site VPN has a route back to each other, this works perfectly.
Based on other posts this is all that should be needed for the Road Warrior VPN, but still not working.
-
Maybe site 2 192.168.10.0 needs a route to roadwarrior vpn 172.16.1.0
-
Just just add 172.16.1.0/24 to the Local Networks on the Site to Site Server configuration for all sites?!?! (Slightly more confused now.)
-
the devices on sites 0,2,3 don't have a route towards your road-warrior subnet (=connected to site1).
so like @beb consulting said:
- @site1 site-to-site configs ==> add 172.16.1.1/24 to the local networks (do this for site 0,2,3)
-
Thanks Heper, I will try adding the RW subnet to all site. I'll update here if it works.
-
Ok, Added the RW Subnet (172.16.1.0/24) to all Sites to Sites under the Local Networks. However still not able to route to Sites 2 or 3 via the RW VPN.
RW still only sees Site 1. I've even restarted all the VPN Connections. Still no routes to sites 2 or 3.
-
are you sure the routes aren't there ? filling in the local/remote networks should create the routes.
provides some traceroutes / packet captures / screenshots of config.
when you start the RW client, you right click it and 'run as administrator' ?
-
It runs as a services
I've attached one example of the server side config from site 2 screen shot, and one of the road warrior side config from Site 1 screen shot.
Also the traceroute attempt from a Road Warrior Client to Site 2, which fails at first IP.
Also a traceroute from the same Road Warrior Client to Site 1, that works just fine.
default 104.153.44.121 UGS 12042069 1500 em1
google-public-dns- 104.153.44.121 UGHS 2582783 1500 em1
10.1.1.0 link#3 U 3612750 1500 em2
10.1.1.1 link#3 UHS 0 16384 lo0
104.153.44.120/29 link#2 U 918385 1500 em1
104.153.44.123 link#2 UHS 0 16384 lo0
104.153.44.125 link#2 UHS 248410 16384 lo0
localhost link#8 UH 257424 16384 lo0
172.16.1.0 172.16.1.2 UGS 43319 1500 ovpns1
172.16.1.1 link#10 UHS 0 16384 lo0
172.16.1.2 link#10 UH 57 1500 ovpns1
172.16.2.1 link#11 UH 12 1500 ovpnc2
172.16.2.2 link#11 UHS 0 16384 lo0
172.16.3.1 link#12 UH 8 1500 ovpnc3
172.16.3.2 link#12 UHS 0 16384 lo0
192.168.0.0 172.16.2.1 UGS 2047600 1500 ovpnc2
192.168.10.0 172.16.2.1 UGS 353061 1500 ovpnc2
192.168.40.0 172.16.3.1 UGS 214494 1500 ovpnc3
192.168.50.0 link#5 U 996 1500 em4
192.168.50.1 link#5 UHS 0 16384 lo0
192.168.50.50 link#5 UHS 0 16384 lo0
192.168.100.0 link#1 U 4253299 1500 em0
pfSense01 link#1 UHS 6 16384 lo0
192.168.100.50 link#1 UHS 0 16384 lo0
192.168.200.0 link#4 U 992 1500 em3
192.168.200.1 link#4 UHS 0 16384 lo0
192.168.200.50 link#4 UHS 0 16384 lo0
Roadwarrior-client-TraceRT.txt
Roadwarrior-client-TraceRT2site1.txt
[packetcapture to site 1.pcap](/public/imported_attachments/1/packetcapture to site 1.pcap)
[packetcapture to site 2.pcap](/public/imported_attachments/1/packetcapture to site 2.pcap) -
Any suggestions? Made changes in the other recommendations here. Nothing has worked thus far.
-
It sounds like you were given the right info, but the wrong implementation. First things first, your issue is that your remote sites do not have a return route to your road warrior subnet (172.16.1.0/24).
According to your diagram, site 1 is the server… so, you need to add 172.16.1.0/24 to all the client sites (0,2,3) in the "IPv4 Remote Network/s" section (not the local network section on the server… you can remove those entries).
Once you have everything working, the next order of business would be to get off that 192.168.0.0/24 subnet on site 0... it's too common... you're just asking for issues down the road.
-
Thanks I will give this a try.
We have to use 192.168.0.0/24 for our internal network. We currently use all the follow superblocks for our network.
192.168.0.0/16 - DataCenters/Branch Offices Server/workstations/Wired Laptops
10.0.0.0/16 - VPN Internal/Building WIFI
172.16.0.0/16 - Employee VPN/Customer VPN/Site to Sites/ISCSI SAN/Cloud Services.
So we are limited on what we can use. But thanks for the suggestion.
-
Thanks, that slight change corrected the problem. We now have working Road Warrior VPN routing through all sites to site VPNs, and all application/databases are reachable via road-warrior.
Thanks so much!
-
Excellent! Glad it's working.
Regarding the issue with the 192.168.0.0/24 subnet, obviously everything being ideal you'll be fine, but every time a VPN user behind a home router on that same subnet tries to access site 0 it will generate a phone call because the routing will be broken.
Also, with some clever subnetting, you could get away with a quarter of the ranges you're using… but typically you have to play the hand you're dealt... and it's a whole bunch of work to re-ip an org.
-
Well the site 0 (192.168.0.0/24) has not been brought up fully yet, so I might be able to get that changed. I'll speak to our NE. Any ways now I have a new issue on the same topic.
We just upgraded all the sites (1,2,3) (again 0 is not up fully yet) to Pfsense 2.2.3. Prior to the upgrade routing though the RoadWarrior worked through to all the sites, however after the upgrade now routing to just one site via the RoadWarrior VPN fails with:
TTL expired in Transit.
We have rebooted all the VPNs, (all site to sites, and the Roadwarrior) and still nothing works.
Routing to 192.168.100.0/24 and 192.168.40.0/24 work fine. However 192.168.10.0/24 fails with the TTL errors.
Doing a trace route from a Roadwarrior laptop to 192.168.10.1 gives me:
C:\Users\Administrator>tracert 192.168.10.1Tracing route to 192.168.10.1 over a maximum of 30 hops
1 56 ms 56 ms 56 ms 172.16.1.1
2 102 ms 102 ms 227 ms 172.16.3.1
3 350 ms 162 ms 103 ms 172.16.3.2
4 151 ms 149 ms 149 ms 172.16.3.1
5 150 ms 148 ms 148 ms 172.16.3.2
6 196 ms 195 ms 194 ms ^C
C:\Users\Administrator>It looks like a routing loop on the Site to Site from Site 1 to site Site 2. But the configs worked just fine before.
Not sure why the upgrade would have broken the working routing, but it appears it has.
Any thoughts? Suggestions.
BTW, I am going to pull ALL the routing referencing 192.168.0.0/24 for now, as the site is not up and eliminate the possibility that that route is trying to be used by something somewhere. Once our NE changes the addressing for site 0 (if he is willing at this point) I can put it back.
-
Update:
Now the issue seem to have move to the 192.168.40.0/24 network. It appear the routing loops is alternating between the 192.168.10.0/24 site and the 192.168.40.0/24 sites.
-
Fixed my own issues, had to pull out the routing under Advanced, at each of the server side site to sites, leave the 172.168.1.0/24 in the remote network sections, and put push routes in the Roadwarrior server side.