Routing between multiple sites
-
So I have an interesting problem, I have 3 sites, each with a pfSense firewall:
PDXFW1: (LAN: 192.168.1.1/24)
SEAFW1: (LAN: 192.168.2.1/24)
SLCFW1: (LAN: 10.7.3.1/24)They are connected like so:
SLCFW1:10.7.30.2<openvpn tunnel="">10.7.30.1:PDXFW1:192.168.10.253<mpls link="">192.168.11.253:SEAFW1
The idea being that all devices on all LAN's can freely communicate with one another
The problem is routing from SLCFW1's LAN to SEAFW1's and vice versa.
SLCFW1 has SEAFW1's LAN net as a remote network in the Open VPN config
SLCFW1 can route just fine to PDXFW1's LAN and vice versa
SLCFW1 can ping SEAFW1's LAN Address from its Open VPN interface but not it's LAN interfaceSEAFW1 has a static route sending traffic to SLCFW1 via PDXFW1's MPLS interface
SEAFW1 cannot route any traffic to SLCFW1, acccording to a traceroute it dies in PDXFW1
SEAFW1 can route to PDXFW1's LAN just fineWhat am I doing wrong?</mpls></openvpn>
-
I do these kinds of OpenVPN circuits all the time using one location in the middle of other locations..
Im curious if running RIP on the MPLS interfaces would solve your issue.What does your OpenVPN firewall rule look like at PDX? What is showing up in your firewall logs when traffic tries to flow?
Do you have your OpenVPN assigned to an actual interface at SEA and PDX? ( I actually do not here..)
Id also be curious about running an OpenVPN connection across the MPLS circuit.
-
Id also be curious about running an OpenVPN connection across the MPLS circuit.
Out of sheer curiosity: what problems can arise from that combination (and why)?
-
What does your OpenVPN firewall rule look like at PDX? What is showing up in your firewall logs when traffic tries to flow?
All VPN interface rules are allow any to any.
Nothing, it just dies without getting blocked.
Do you have your OpenVPN assigned to an actual interface at SEA and PDX? ( I actually do not here..)
No I do not, and the VPN is between SLC and PDX, not SEA.
Id also be curious about running an OpenVPN connection across the MPLS circuit.
That's what I was going to try next if I couldn't get an answer here
-
you are probably missing a return route somewhere. not enough information to go on.
best to draw up a detailed schematic ( = no ascii art) with all the subnets involved. also provide the (redacted) routing tables on all sites
-
Will do, I'll work on nice shiny schematic
-
Id also be curious about running an OpenVPN connection across the MPLS circuit.
Out of sheer curiosity: what problems can arise from that combination (and why)?
I probably need to reword that..
Id be curious if creating an OpenVPN tunnel inside the MPLS circuit between the two boxes wouldn't easily solve the routing problem.. :)
-
All VPN interface rules are allow any to any.
Nothing, it just dies without getting blocked.
Ive had issues in the past with Any/Any firewall rules although I didn't stick around long enough to diagnose so it was probably something else at the time.. But I tend to always get specific these days. YMMV.
You could always try the Routed Package on the two machines and see if that doesn't help. Use the MLPS interfaces.
-
Ok here's the diagram: https://www.lucidchart.com/invitations/accept/abf0f5c5-d92b-4c5b-9d8b-a527a746765d
-
You could always try the Routed Package on the two machines and see if that doesn't help. Use the MLPS interfaces.
Was in a hurry so spit this out too quick..
Save your configs.
Put the Routed package on both SEAFW1 and PDXFW1.
Set up Routed on both machines to be on their MLPS interfaces.
Routed will allow the machines to advertise their subnets to the other machine much the way that the OpenVPN config is doing between PDXFW1 and SLCFW1.
Get rid of the static routes.
Im assuming each router has its own local internet connection.. ?
-
Ok here's the diagram: https://www.lucidchart.com/invitations/accept/abf0f5c5-d92b-4c5b-9d8b-a527a746765d
No. Not going to create an account there just to view your diagram.
-
-
Your MPLS needs to know about the routes to SLC. Is the traffic for the networks at SLC even arriving at PDX from SEA?
-
Hi All, this was finally fixed today. The issue was that an old IPSEC connection to SLC was still set to enabled on the SEA router and was screwing up routing.
Interestingly this never was shown in the system routing table which is frustrating.
Anyway it is fixed now. Thank you all for your help!
-
@amundae IPsec traffic selectors are not in the routing table because they are not routes.
https://forum.netgate.com/topic/131420/routed-ipsec-using-if_ipsec-vti-interfaces
