IPSEC Site-To-Site As Gateway to Corporate
-
I have an interesting setup that seems to work (with some babysitting) but is clearly not ideal.
On one end, I have PFSense. On the other end I have a Juniper SRX.
The Juniper is setup to for an IPSEC connection for my location. Furthermore it has assigned a specific /30 subnet for my location as a gateway into the corporate netowork.
In my scenario, I have my local LAN as: 172.18.13.0/24
The tunnel is setup as 10.250.0.52/30
My side of this tunnel is 10.250.0.54 and the remote side is 10.250.0.53When I setup a phase 2 tunnel, with:
Local: 172.18.13.145 (address)
NAT/BINET: 10.250.0.54 (address)
Remote: 10.250.0.53 (address)
and a VIP added for the firewall of 10.250.0.54With this I can ping 10.250.0.53 thru the tunnel and vice versa. This is great but since 10.250.0.53 is a gateway address, that's as far as I can go.
The problem is that I want to reach the 10.20.0.0/16 network on the corporate side.
Pinging and running some packet captures that shows that doing so a packet addressed to 10.20.x.x goes out the WAN interface.
As advised in the forums and dox I added the 10.20.0.0/16 as an additional phase 2 tunnel.
This gets the ping to go out the IPSec interface, but, it is discarded because it is not first sent to the "gateway" address of the tunnel, namely 10.250.0.53 which the Juniper expects.
Now here is the fun part, and although it's clearly a bug, it actually works.
By adding the second phase 2 entry to the config and applying it while the IPSEC is already connected and working. It adds this to the IPSEC:SPD table:
10.250.0.53 10.250.0.54 direction ESP (Added from first phase 2 entry)
172.18.13.145 10.250.0.53 direction ESP (Added from first phase 2 entry)
10.20.0.0/16 10.250.0.54 direction ESP (Added from second phase 2 entry)
172.18.13.0/24 10.20.0.0/16 direction ESP (Added from second phase 2 entry)If I then change the second phase to entry to:
Local: 172.18.13.0/34 (network)
NAT/BINET: 10.250.0.54 (address)
Remote: 10.250.0.53/30 (network) (<– This is network as opposed to address so that the UI will allow me to have two entries to the same remote)The viola! I get this in my IPSEC:SPD table:
10.250.0.53 10.250.0.54 direction ESP (Added from first phase 2 entry)
172.18.13.145 10.250.0.53 direction ESP (Added from first phase 2 entry)
10.20.0.0/16 10.250.0.54 direction ESP (Added from second phase 2 entry)
172.18.13.0/24 10.20.0.0/16 direction ESP (Added from second phase 2 entry)
10.250.0.52/30 10.250.0.54 direction ESP (By adjusting the second phase 2 entry)
172.18.13.0/24 10.250.0.52/30 direction ESP (By adjusting the second phase 2 entry)And I can now route traffic thru the gateway to the 10.20.0.0/16 as required!
It appears that it does not delete the existing data in the SPD table is pfSense still thinks to send the packet out the IPSEC interface!
How i stumbled upon this is a matter of serendipity. All the stars must have aligned that day.
The issue is this. As soon as the IKE is closed, I have to go back in, make the changes to fool it again, and then Im back online for ~24 more hours.
My question is, is there a better way? And, is it possible to tell PfSense to route the 10.20.0.0/16 thru the first phase 2 entry without all of this drama? Could that be added as a feature for IPSEC tunnels?
Thanks in advance for any help!