VPN - Routing Issue - Only Linux Hosts
-
Thanks guys.
I'm heading out of office for the day but will post a diagram with details tomorrow and you can tell me what else to add to help figure it out.
Hopefully as I document it, perhaps something will jump out.
For now at least it works, even if I've just sort of put a band-aid on it.
Thanks again and talk to you tomorrow!
-
Yes, seeing how your vpn interface is configured should be revealing.
One thing that seems like it can cause this is having both subnets on the same interface. I'm struggling to see how that might apply here though.Steve
-
From a quick scan of this thread, I would guess that the netmask/CIDR on pfSense has been set (accidentally) to cover both the 25 and 26 networks - 172.26.10.254/15 (or smaller) would cover all that and cause pfSense to think that 172.25.n.n is on its LAN and thus send a redirect message back to the client.
-
^ Agreed, I never understand how people come in here asking without some diagram.. I can not believe a company that has multiple locations and a site to site vpn do not have a network drawing??
-
you create docs/schematics ?
some of us seem to have the luxury of collegues and spare time ….i only know people who get abused by their employer todo a 5-man-job ; on their own :D
-
Yes, unfortunately it doesn't surprise me at all. And in fact i'd go further and say that very often network issues can be caused by an existing network diagram that's out of date or just plain wrong. I have always found it prudent to assume nothing. Perhaps just my own experience. ::)
Steve
-
Thanks again everyone that's helped. Comments about lack of documentation duly noted as well. I am guessing there is a more elaborate network diagram with the main office guys that sort of support the network, but it is likely not fully up to date as well. We're not a very large company so we do not have a fully dedicated group or person that supports the network. If we did, they might have tried to force a Cisco ASA on me some time ago. The fact I can more or less support what I've got has helped me and pfSense is really the reason I can support it, because it's straightforward to use.
The person that originally reconfigured our company network decided to set up the main office and my office with very large LAN subnets for some reason. So, you will see in the image that the main office is 172.25.0.0 - 172.25.255.255 and my office is 172.26.0.0 - 172.26.255.255. We likely could/should have been all on 172.25 with the next digit being the assigned to each office and the last being left for all the hosts within the office. But, no matter, that is how it is set up.
When I first set up this remote office, we had no VPN connectivity at all. I think I started with some Linux firewall distribution and then later used monowall and that lead me to pfSense. I think it's been here since one of the very, very early releases. All that being said, I'm a middling sort of network person so mistakes in the setup would not exactly be surprising. Part of what is awesome about pfSense is the traffic shaping which has been huge for me because I use hosted VoIP for my office phone system.
I've attached a very basic image that describes some of what I've mentioned along with the relevant pfSense screens (parts of them anyway), so you can see the setup. I'm guessing one of you experts will notice something right away, which is appreciated.
Thank you again for your help on this.
![pfSense VPN Info.JPG](/public/imported_attachments/1/pfSense VPN Info.JPG)
![pfSense VPN Info.JPG_thumb](/public/imported_attachments/1/pfSense VPN Info.JPG_thumb) -
This does not look right - see attached.
You have the gateway setup for the remote 25 network as your lan interface 26.10.254 on pfsense???
Where is your phase 1 details when you setup the tunnel? You wan interface is normally your endpoint for the tunnel.
-
When you mentioned routing, I started looking around and found a specific routing entry for the VPN. I am not sure why it's there, but it is. I did some reading on VPN setup in pfSense and it seems that the routing over the tunnel takes care of itself so no specific routing entry like this should be needed.
So, I removed this, re-enabled the redirect setting in system tunables back to the default and rebooted the linux machine (to be safe). I can still ping IPs on the other end of the tunnel, so that's great!
That introduced a new issue with DNS resolution over the VPN for our domain. I figured that out with some searching but will post the details here so it might help another person later.
Basically in the DNS forwarder where you can specify a domain override, I had to also specify the LAN IP of pfSense (172.26.10.254 in my case) as the "Source IP" on the domain override configuration. Once I did that, lookups for our domain worked perfectly again.
So, at the end of the day, the issue was the static route that I added and then the IP on the DNS domain override. I assume I did the route entry to try and "tell" pfSense to send traffic for the remote VPN someplace. And oddly, it worked until now.
But, it now seems that all is well and I've only got the configuration in place that is needed.
Thanks again everyone!
-
Basically in the DNS forwarder where you can specify a domain override, I had to also specify the LAN IP of pfSense (172.26.10.254 in my case) as the "Source IP" on the domain override configuration.
You usually have to do that when the DNS server that services the domain in question is over a VPN, because otherwise the source IP of the request (from the pfSense, across the VPN to the DNS server) will be some IP address of a VPN tunnel endpoint, or some internal tunnel address. The remote DNS server typically won't have a route back to that and so the reply to those DNS queries would never make it back.