IPSec tunnel with public ip in phase 2 (BINAT/Port Forward)
-
Hey all,
we are currently evaluating differnet IPSec options. Our plan was to use one of our public IPs in phase 2, as we have seen it by a lot of customers. We tried multiple ways of configuration, but still have some problems.
At first we tried instead of BINAT, to give our pfsense a VIP (the public address we want to use in P2) and configure it as local ip in Phase 2. After that we created a port forward from the public IP to our internal system:
P2: local - w.x.y.z; remote a.b.c.d
NAT portforward - w.x.y.z:20022 -> e.f.g.h:22
After connecting from a.b.c.d to w.x.y.z:20022 we were able to see the traffic arriving on the targetsystem e.f.g.h:22, but the traffic is lost on the way back (even after creating a static route to a.b.c.d via w.x.y.z). We see the packets going back from the targetsystem, but not any further (on the firewall).
Does anyone got a similar setup and got it completly working? Any hints are highly appreciated!
Additionally we tried to do a BINAT with the public IP, but the results were similar. We saw incoming traffic, but no outgoing traffic from the firewall again.
Greetings,
ynk93
EDIT: The version of pfSense we use is 2.4.4-RELEASE-p3
-
pfSense does not care if the address is routable or RFC1918. It just doesn't.
The reason people do that is to avoid conflicts with other networks' RFC1918 addresses.
You don't use static (or any other) routes with IPsec unless you are using VTI. It is all handled by the IPsec traffic selectors (the Phase 2 networks).
If you have a local network (10.11.12.0/24) and want to present a single public address (198.51.100.123) to the remote network (172.16.223.0/24) you would do this:
Local Network: Network: 10.11.12.0/24
BINAT: Host: 198.51.100.123
Remote Network: Network: 172.16.223.0/24The other side would do the equivalent of this:
Local Network: Network: 172.16.223.0/24
Remote Network: Host: 198.51.100.123You will, of course, run into issues if the other side wants to establish connections to your side. You might be able to work around that with port forwards on the IPsec interface.
-
Sorry for the late reply... You are our hero!
I feel kind of stupid, as we did not tested it like this.Best wishes,
Yannick
