Traffic from IPSEC tunnel A is not being natted before going through IPSEC tunnel B
-
I would like to be able to access PC1 at location X while connected to ServiceHQ.
So far working is traffic from ServideHQ is natted to 10.12.0.5 with nat rules on
the PFsense to the virtual machine (10.12.0.2) at the cloud provider. The
virtual machine (10.12.0.2) can access the PC1 (10.12.1.2) at location X and is also
natted correctly.The problem is with data coming from the ServiceHQ (source ip 192.168.4.254)
that needs to go to PC1 (10.12.1.2). I would like to have this traffic natted so
source ip: 192.168.4.254 is first converted to for instance 10.12.0.5 and then
send through VPN2 tunnel so the Cisco881 handles it as normal 10.12.0.0/24
traffic. This is important as i am not allowed to change the Cisco881 and PC1
configuration. It looks like PFsense doesn't allow or understand what to do
with natted traffic taking place on data coming from VPN1 that need to be
reentered (re routed?) and send through another tunnel (VPN2).Hopefully someone can provide me with some settings or tips to get this
working with PFsense.Please see network layout below for more info.
-
I did some more testing but still could not get traffic from/to the facility A from serviceHQ.
When i look at the traffic with the packet capture i see that traffic is coming into the pfsense firewall from
the VPN1 tunnel as 192.168.4.254 traffic and forwarded to the gateway 10.12.0.5 This triggers NAT translation
and translates traffic for 10.12.1.254 as source 10.12.0.5 (instead of source 192.168.4.254) so thats allright. The
traffic indeed goes to Facility A and a reponse is coming back to the PFsense firewall for 10.12.0.5 but this
is where things go wrong. I expected this traffic was state tracking denatted to 192.168.4.254 and send back
to 192.168.4.254 but the flow stops at exactly this moment. See also packet capture log below:14:56:47.112519 (authentic,confidential): SPI 0xc047276e: IP 192.168.4.254 > 10.12.1.254: ICMP echo request, id 1, seq 5875, length 40
14:56:47.112679 (authentic,confidential): SPI 0x3a7593a8: IP 10.12.0.5 > 10.12.1.254: ICMP echo request, id 44111, seq 5875, length 40
14:56:47.119776 (authentic,confidential): SPI 0xcc06fe21: IP 10.12.1.254 > 10.12.0.5: ICMP echo reply, id 44111, seq 5875, length 40I think this problem has to do with the fact that traffic is natted from the inside nat and denat isn't matched because response comes back from IPSEC interface. I don't know how to solve this with PFsense. I also find it rather strange that the standard approach creating an outbound nat for IPSEC interface for 192.168.4.254 to 10.12.0.5 doesn't work. That was
the thing i tried in the first place, but since this traffic wasn't natted i created a gateway to force traffic on this interface and apply NAT.Please also see below settings currently in use on my PFsense setup. Hopefully someone still can provide me with some tips.
-
Ok, i found a way of getting the traffic natted. It feels more like a workaround, but for now it is working; i found
some help on internet when searching for 'NAT before IPSEC'. I found a very old topic stating PFsense was unable to do this because of BSD operating system missing something. Later this got fixed and a option was added for BI-NAT in the phase 2 settings of the IPSEC tunnel. I started to mess around with the phase 2 settings until i found the correct combination.I was under the impression that the BI-NAT option in phase 2 was only needed if you want to produce a different IP on the other side of the tunnel. In a sense this is still what is happening, but i thought the interesting traffic (phase 2) selection for the tunnel should still be local subnet 10.12.0.0/24 and 10.12.1.0/24 for remote, but this was where things went wrong. I had to add a phase 2 traffic selection for 192.168.4.0/24 (keep in mind this actually isn't local 'traffic') as local subnet and 10.12.1.0/24 as remote subnet and enabling the BI-NAT by using 10.12.0.0/24 as address range for BI-NAT. This extra phase 2 made sure the 192.168.4.0/24 traffic from VPN1 (ServiceHQ) got natted before going in VPN2 (to Facility A).
I also did not had to add any NAT rules. I just used the automatic settings.Also see the VPN settings below:
-
Hi i am having a similar problem ..did you create two phase twos or just one..
i have a client that i have to configure the following,
they already have the same local network as ours.. that is on Site A and Site B they are both on the 192.168.13.0/24 network.. so we had to use a 172.23.0.0/27 network in between.. and i have to configure the nat such that specific ip address that are pinged from Site B e.g 172.23.0.1 will be translated to 192.168.13.4 on our side(Site A).
Can you hep? -
Hi, I think you are having somewhat different problem.
As far as i now understand PFsense i think i know how to get this working with two
PFsense firewalls. Although it could also work with Cisco and/or PFsense combo.You did not describe the exact setup of your network topology so i will for now make an assumption that you want to create a VPN IPSEC site-to-site tunnel between two PFsense firewalls, each having the same local subnet. I will also make an assumption that you want to be able to reach Site B from Site A and vice versa. This is what i understand called BI-NAT in PFsense. Keep in mind i did not work with PFsense before (only Cisco and Linux netfilter) so
maybe some of my guesses are wrong :-) For true BI-NAT i would expect you need exactly the
same subnet size on both sides, since the mapping should match all network addresses in order to create traffic in both directions 1-on-1 for each mapped IP address.I am guessing your network topology looks like:
(SIDE A)
(Local Network)192.168.13.0/24 [BINAT network 172.23.0.0/24]
(Remote Network) 172.23.1.0/24 <--- i know it is actually also 192.168.13.0/24, but the VPN interesting traffic is actually seen as 172.23.1.0/24 because of the BI-NAT configuration on side B.(SIDE B)
(Local Network) 192.168.13.0/24 [BINAT network 172.23.1.0/24]
(Remote net) 172.23.0.0/24 <--- i know it is actually also 192.168.13.0/24, but the VPN interesting traffic is actually seen as 172.23.0.0/24 because of the BI-NAT configuration on side A.Whats happening with this configuration is that a VPN IPSEC tunnel is build for the subnet 172.23.0.0/24 <> 172.23.1.0/24 and the actual local/remote subnet 192.168.13.0/24 is mapped 1-on-1 for each IP address.
Keep in mind you still need to allow traffic between the subnets by adding firewall allow rules. If traffic isn't flowing, first check the system logs->firewall to see if packets are blocked.
I hope i got it right. Please let me know if it worked or not.
-
wow.. exactly the way you described it... i am so grateful that you took the time to answer me.
the mistake is that the BINAT Network is a /27 network.. so that i will have to have them change...But i will still have to make some specific ip addresses on SITE B.. to translate to specific addresses on SITE A.. can i still then use the 1 to 1 nat in pfsense to achieve this ?
the connection is between a pfsense and a baracuda firewall.And yes the firewall rules are also in place
-
I still think this works. I will for now assume Site A has the PFsense firewall and Site B the Barracuda firewall.
I would configure the PFsense firewall exactly as i described earlier. I don't have any experience with barracuda firewall's
but if i understand correctly from the internet, you should configure map access rule and nat table for mapping the IP addresses:https://campus.barracuda.com/product/cloudgenfirewall/doc/53248692/how-to-create-nat-tables-translation-maps
Use this to convert (SNAT - source network address translation) the source IP addresses of your outgoing traffic at Site B
to IP addresses in the BINAT address range of Site B. So i think you should write a rule that converts your outgoing packets source IP addresses from the original network 192.168.13.0/24 to translated base address IP 172.23.1.0/24https://campus.barracuda.com/product/cloudgenfirewall/doc/53248337/how-to-create-a-map-access-rule
Use this to convert (DNAT - destination network address translation) the DST IP addresses of your incoming traffic from Site A to IP addresses in your local IP address range at Site B. So I think you should write a rule that converts your incoming destinaton ip addresses from Mapped IP address range 172.23.1.0/24 to Real IP address range 192.168.13.0/24Keep in mind that the VPN IPSEC tunnel on the barracuda side knows nothing about the translation happening on the PFsense firewall, so the VPN connection (at barracuda config) should be between local 172.23.1.0/24 to remote 172.23.0.0/24
-
Thank you very much .. will try it out and get back to you .. i did not configure the baracuda side.. but i will make the changes on my side (site A)