Routing through multiple IPSEC tunnels



  • I am working on an implementation that has a complex routing scheme in place (via some Cisco routers) that I am trying to replace with pfsense.

    The client has two locations.  Network A is 172.26.153….  Network B is 10.16.25.....

    I have a tunnel between them that works without issues.  The problem I am trying to resolve is that Network B also has a second VPN connection to a vendor that uses 10.83.10 on the private side and has a public ip at the other end of the tunnel.  (100.100....).

    I need to get traffic from network A to this 100.100 address.  I can set up a phase 2 ipsec connection that will get traffic for either 100.100... or 10.83.. to the 10.16.25 network, what I can't figure out is how to then implement the next hop from the 10.16 network to the 10.83 and/or the 100.100.

    It would help if I could get the configurations of the cisco boxes, but the vendor is big and very proprietary and will not share the current configurations.  (They make an large amount of revenue "renting" the current equipment to the client - so I can understand their reluctance to any replacement)

    Any idea if this can be accomplished or am I better off leaving the current cisco routing in place?  I'd be willing to get commercial support involved, but I need to know if it is feasible to replicate the current structure first.



  • I have worked on this for the last day or so and I have most of it now working but I am stumped on the last piece.

    I have a server on network A @ 172.26.153.100
    The PFSense router is @ 172.26.153.253

    There is a tunnel built from there to the PFsense router on network B @ 10.16.25.253

    I have a second Phase 2 entry with 172.26.153/24 at one end and 100.100.1.0/24 at the other end.

    On the 10.16.25.0 network I have a gateway 10.16.25.250 that passes traffic to a separate (cisco) VPN connection to the 100.100 network.

    I have a static route that sends all traffic for 100.100.1.0/24 to this gateway (10.16.25.250)

    I have Manual Nat entries for the 10.16.25 network and the 172.26.153 networks.

    From the server (172.26.153.100) I can contact a server at 100.100.1.1

    However, the server at 100.100.1.1  can not contact the server at 172.26.153.253

    From 100.100.1.1 devices on the 10.16.25 network can be reached but the last hop does not happen.

    I am sure I am missing one last piece of the equation but nothing I have tried seems to have worked.  (Of course since I have no access to the 100.100.1 network, I have to rely on someone there to test the connection.)

    Any idea what I might need to complete the connection?



  • Looks like you can access the 100.x network from the 172.x network because it is being NAT'ed at your 10.x hop. Does the 100.x host have any way of knowing it should reach the 172.x network through the 10.x hop?



  • Thanks, but yes I believe that the 100.100 host knows to route to 172 through the 10 network.  This was working when it was a set of Cisco routers so I am just trying to replicate what was already working.  (Without any knowledge of how any of the cisco routers were configured).

    I puzzled about this last night and I think that the problem may be the way I have manual outbound nat configured on the 10.16 router.  I started with the instructions for getting all traffic to pass through the 10 side of the network going to the internet and modified them to just deal with the 100.100 traffic.  As a result, I configured the advanced outbound NAT rule to use the WAN interface - but this traffic is never going to the WAN - I think that perhaps I need to switch this to the LAN interface.

    Unfortunately, the 100.100 end can only be tested between 9 and 5 so I am waiting to get the results from testing the current configuration before I make any additional changes.



  • I seem to have reached a point where nothing I am trying results in any progress.

    In short the cisco device attached to the 10.16.25 network has an FE1 port that is connected to the 10.16.25 network.  and an FE2 port that is connected to the 100.100 lan.  (it has a 10.93… network address).  From the FE1 side, which has a 10.25.16.250 address, traffic can reach the PFSense router and pass through the VPN to the 172.26 network.  From the FE2 side the traffic can not pass through the PFSense router.

    I see the traffic in the firewall logs from the 10.93 address as being blocked by "@3 block drop in log inet all label "Default deny rule IPv4"  I've tried setting "Bypass firewall rules for traffic on the same interface" with no change in behaviour.    I looked (and tried) making a specific firewall rule for this traffic, but since I already have a rule allowing all LAN traffic and I've turned on the bypass option, I think that approach is wrong.

    I've made a number of attempts to change the manual outbound mappings that again have not resulted in a change of behaviour.

    What am I missing?



  • I think you are having some issues with your NAT. If the 100.100 host knows to route to 172 through the 10 network as you said, what is that you are NAT'ing??

    BTW, what pfSense version are you using? Only 2.1 and above are able to do NAT before IPsec



  • It seems to finally be working.  The 100.100 network "knew" to route through the 10 network to reach the 172 network.  I knew nothing about the 100 network other than my 10 network was connected to the FE2 port on their cisco router.  I ended up watching the firewall log on the 10 network and discovered that the 100 network was "appearing" on my 10.26 network as being on a completely different network (26.67…..)  I created a manual NAT outbound rule for packets on the LAN side for that network, and translated them to the interface address.  That seems to have done the trick.  I still need to verify it with the vendor tomorrow, but I can see activity on the target server.    I'd like to find out exactly what the vendor is doing on the other side of that router.  Even though it is working, I'm not certain I really understand the mechanics behind why it is working.    Thanks for your suggestions.