OpenVPN traffic does not route unless I set the LAN default gateway to another router
-
Hi all!
I come presenting with a strange issue. For some reason, my OpenVPN config would refuse to return pings unless I set the LAN gateway of my pfsense Router A to another router's interface (Router B). As soon as I set the Lan default gateway to another router, the OpenVPN config starts working again. This essentially forces the other router to route all traffic. Is there a way I can get this to work without the other router?![alt text]
Thanks in advance!
-
@proxmoxman said in OpenVPN traffic does not route unless I set the LAN default gateway to another router:
my OpenVPN config would refuse to return pings unless I set the LAN gateway of my pfsense Router A to another router's interface (Router B).
What do you mean with "LAN gateway"? Do you have stated a default gateway on the LAN in the other case? If so, which and why?
Which OpenVPN is it? A server or a client?
If a server, is the connection coming in through WAN A?
What's the purpose of running to routers in your network?
-
@viragomann Thanks for the reply.
- I probably should have clarified LAN gateway more. It basically means I went to the LAN interface and set a default gateway to another router. The router is able to ping all it's connected interfaces without it, but OpenVPN refuses to ping those interfaces. This would mean that router would esentially handle all routing on the network. I have another OpenVPN server running on the same router that works fine without the need for me to do any additional steps.
- It is OpenVPN server.
- The reason why I have 2 routers is for redundancy. They use different ISPs.
Mostly I'm just wondering why the OpenVPN isn't working for directly connected routes. The switch doesn't have anything special running on it. Funny enough on my second router, I tested installing OpenVPN on it and it works perfectly (they are both connected to the same switch and same devices).
-
@proxmoxman
If you're talking about access from a VPN client to the LAN host, I would expect this, if the router B is the default gateway on the host.However, the only I can think off, why the other VPN is working then, is that there must be a static route on the host for the source IP of the packets pointing to A.
Is the second VPN a site-to-site?The reason why I have 2 routers is for redundancy. They use different ISPs
pfSense can also handle multiple WANs. So why do you run a separate router for each?
If it's for the sake of hardware redundancy you should better set up a HA system with both pfSense. This would prevent routing issues like that. -
@viragomann I think you're right. I just thought it was strange that the VPN tunnel wouldn't work for a directly connected route. Could it be related to the fact that all devices on the network have a different default gateway than the LAN interface of the router I'm using the VPN tunnel on?
-
@proxmoxman
Yes. This issues might strike any incoming traffic, not only VPN. But possibly you don't have another on A.I should add, you could get it work though by masquerading the source IP on the router. This is done by adding an outbound NAT rule to LAN, translating the source IP in outgoing packets into the interface IP.
So your LAN device respond to the interface IP and pfSense would forward it to the VPN clients. -
@viragomann Thanks for taking your time to reply to my question! I guess I will look into creating an HA environment instead. The current solution still works but it's just not a great solution. My switch is a managed switch and supports VLANS so I will probably look into creating seperate networks and then using static routes to route the traffic to those seperate networks. I am assuming all I would need to do is create the static routes as well as using the "route push" command to all the networks that the VPN will need to pass through?
-
@proxmoxman
I think, you got me wrong. The issue is not the route to the destination devices, but the route back of their responses.
Since the devices don't have a specific route for the source IP of the packets, they send responses to the default gateway, which might be router B.
To solve, you would need a static route for the source IP pointing to A on each destination device or even masquerading on the router.If the devices pull their network settings from a DHCP server you could distribute the route by DHCP.
-
@proxmoxman if you have a vpn coming in on wan A.. And your host has router B as its gateway the simplest solution without any network change is to just create an outbound nat on pfsense (router a).
This setup is never going to work when host uses router B as its gateway..
So that when vpn comes in talking to host, the host thinks its Router A lan IP, and sends the answer back to router A.
It is what you would accomplish with setting router A lan gateway to B.. When you set a gateway on an interface in pfsense, it thinks of it as a wan interface, and auto creates outbound nat on that interface.
The problem with that method your using, if you actually tried to use router A as the hosts gateway - your going to have issues.
Just setup an outbound nat on router A lan interface.
A better solution would be to redesign the network so pfsense just has 2 wan interfaces, and then you could policy route clients out any internet connection you want, etc.
Another solution would be to create routes on your host(s) so that if they see traffic from your vpn clients IP (your vpn tunnel network you setup in pfsense).. They know to send that traffic back to A IP vs router B.
But doing an outbound nat would me only having to touch pfsense, and not create routes on all your hosts, etc.
-
@johnpoz Thanks for the reply. Would you mind going into a bit more detail for the outbound NAT? What would I need to map the outbound NAT to? I do already see an outbound NAT for my LAN interface with all the addresses (including VPN Client addresses) which is an auto created rule. What would be the source/destination of the outbound NAT?
-
@proxmoxman the source would be what your tunnel network is for your vpn setup. I believe it defaults to like 10.0.8/24
The destination would be your lan network, defaults to what 192.168.1/24
You would need to put in whatever networks your using. This would be after you change from auto mode to hybrid mode.. Remove the gateway setting on your lan interface.
Lets say your tunnel network is 10.0.8.0/24 - and your lan is 192.168.1.0/24
Pfsense lan IP is say 192.168.1.254.. your host is say 192.168.1.100
Now some vpn client coming in 10.0.8.X wanting to go to 192.168.1.100, pfsense would nat that traffic to look like its coming from its 192.168.1.254 address.
Your host says oh this guy 192.168.1.254 (your vpn client) wants to talk to my service I am running, and sends its answer back to pfsense IP since that network is local to me I am on the 192.168.1/24 and so is the guy talking to me.. Vs say what is this 10.0.8.x IP - I don't know how to get there, its not my local network - send that to my gateway (routerB)
This exactly what you were doing when you set a gateway on your lan, but lan is not actually a wan interface - so what you want is just the outbound nat to trick clients seeing traffic from your vpn clients to send it back to pfsense.. Pfsense oh you really want to talk to this vpn client - and will send it on to the vpn client.
I wouldn't do it this way ;) But this is how you get around talking to clients that have no gateway, or point to a different gateway then pfsense.
How I would do it is setup my 2nd ISP connection as just a wan interface on my pfsense, and then I could policy route, load share, whatever - and I would have to do any source natting to allow vpn clients be it they come in on isp A or isp B to talk to my local network(s).
-
@johnpoz Wow that makes a lot of sense! Thanks, so it's basically using the same process WAN outbound rules. I think in Cisco terms they classify this is PAT (Port address translation)? So basically the LAN interface is almost like the WAN interface for traffic going outside but this time in reverse. I'm assuming some kind of port number gets associated for when the traffic comes back in?
I do agree it's probably a lot better to have just one router. I'm assuming I could just set one of the OPT ports as a second WAN and just create outbound rules for those ports. We just had an extra router lying around so we though it would be better for redundancy just in case one of the routers go down. Regardless, thank you for your excellent explanation!
-
@proxmoxman yeah that is what all router do that share a single public IP with multiple devices behind it. It is NAPT (network address port translation)
And yup that is exactly what pfsense does when you say talk to 1.2.3.4 on port 443 on the public internet.. Your client say 192.168.1.100 uses some random source port lets say its 45602, pfsense changes this to may 32014 or something and talks to 1.2.3.4:443 from publicIP:32014 - now when it sees an answer from 1.2.3.4:443 to its public IP:32014 it knows to send that to 192.168.1.100 port 45602
Just look in your state table and you will see this.
example
here is one of my clients (2.200) is my ipad talking to something.. 5223 I believe port apple uses to maintain a connection for push notifications and the like. That 209.x address is my pfsense wan IP.
Your just doing it in reverse when you setup a outbound nat on your lan interface.. All your vpn clients will share pfsense lan IP when they talk to clients on your lan. To these hosts on your lan, its just some local IP talking to it.. So it doesn't send it to its default gateway - your router b.
edit: while this works.. At some point you might want to redo your network so your 2nd isp is just another wan interface for pfsense. This would give you way more flexibility in stuff you might want to do with multiple internet connections. When your ready to do that - just ask, always happy to help.
-
@johnpoz Thanks for the help, it worked flawlessly! I think I should eventually use a single router, it's just hard when your users are demanding no downtime. It's the main reason why we have 2 routers since the old man was still being used by our users and we wanted to upgrade. Regardless, thank you very much for the info and the help! Definitely learned a lot here.
-
@proxmoxman glad you got it all sorted, and happy to be of assistance.
