pfSense and IPSEC lan to lan: a big doubt about the correct implementation
-
Yup, exactly. Adding that should be much less disruptive at site A.
-
Hello Steve,
I have a problem trying to deploy this scenario in the real world.
Before activating the IPSEC between the pfSense instances I did these actions:- In the site A, I created the virtual fw (pfsense) and I added the following route to the virtual router on the left of the schema: ip route add 192.168.200.0/24 via 10.99.0.2/30
So, in this way, when the IPSEC will be ready, the hosts belonging to the LAN on the left will be able "to be routed" to the LAN in the right via pfSense. (10.99.0.2)
But I think there will be a problem in the other direction, when the hosts belonging to the LAN on the right will try to reach the 192.168.100.0/24.
In this case, the traffic will not pass through the pfsense, but it will go to the LAN directly.
How IPSEC will manage this case?
What I'm missing? What should I do to make the IPSEC tunnel working?
At this moment, IPSEC endpoints don't connect each other.Thank you in advance,
Mauro -
@mauro-tridici said in pfSense and IPSEC lan to lan: a big doubt about the correct implementation:
But I think there will be a problem in the other direction, when the hosts belonging to the LAN on the right will try to reach the 192.168.100.0/24.
In this case, the traffic will not pass through the pfsense, but it will go to the LAN directly.How would that happen? 192.168.100.0/24 does not exist at site B. pfSense is in the default route there so all traffic will go through it. Anything from 192.168.200.0/24 to 192.168.100.0/24 will match the IPSec policy and be passed over the tunnel.
Steve
-
@stephenw10 thank you for your reply, Steve.
Anyway, there is still something I don't understand.
I will try to do a different question:In my scenario, the virtual firewall at B site can ping the virtual router (1.1.1.1/25), but it is not able to ping the virtual firewall at A site (10.99.0.2). For this reason I'm not able to start the IPSEC session correctly.
Could you please help me to understand where is my error?
In the figure above, virtual FW IP 10.99.0.2/30 is a private IP, right? If yes, how the pfsense in the site B can reach the pfsense in the site A?Sorry, I'm a little bit confused.
Thank you,
Mauro -
@mauro-tridici said in pfSense and IPSEC lan to lan: a big doubt about the correct implementation:
In my scenario, the virtual firewall at B site can ping the virtual router (1.1.1.1/25), but it is not able to ping the virtual firewall at A site (10.99.0.2).
That's expected. 1.1.1.1/25 is a public IP so the firewall at site B can ping it outside the tunnel as long as it allows pings.
10.99.0.0/30 is probably not in the IPSec policy so that traffic is not carried by the tunnel and it's not available publicly.
You shouldn't need to have that in the policy to have the tunnel come up though. You just need to use a 'ping-host' target that is in the policy, so 192.168.100.1 for example. The target does not need to reply to bring the tunnel up.
But you could add that to the policy if you wanted to be able to access the transport subnet from site B.Steve
-
@stephenw10 I'm terribly sorry, but I didn't get it working.
This is what I have done (please refer to the following schema)
IPSEC configuration:
pfsense site B:
phase1 - remote gateway 1.1.1.1/25
phase2 - local subnet 192.168.200.0/24, remote subnet 192.168.100.0/24pfsense site A:
phase1 - remote gateway 3.3.3.3/25
phase2 - local subnet 192.168.118.0/24, remote subnet 192.168.120.0/24IPSec firewall rules are completely open (for testing purpose)
But unfortunately IPSEC tunnel didn't come up.I think that the problem is in the site A, what's your opinion?
- Did you already tested this kind of scenario?
- Do you think that I should do something else on the virtual router (site A) In addition to the existing static route (route to 192.168.200.0/24 via 10.99.0.2)?
- Should I activate the NAT on both the site A and site B routers?
- the default gateway for the pfsense in site A is the 10.99.0.1/30, is it correct?
for testing purpose, I just tried to assign a public Ip to the pfsense in the left side and the phase 1 connectivity seems to be ok (not the phase 2).
Is there some techno's about this kind of usage of ipsec with pfsense? the official documentation describes only the standard scenario.thank you
-
The Phase 2 subnets at Site A don't exist and don't match those at Site B.
The Phase 2 policies have to match otherwise it will fail to establish.
https://docs.netgate.com/pfsense/en/latest/troubleshooting/ipsec-logs.html#phase-2-network-mismatchAssuming the 10.99.0.0/30 transport subnet is not public the tunnel can only ever establish from site A to site B. That's fine it should work. If you forward IPSec traffic in the site A virtual router to pfSense that would allow the tunnel to establish either way. But again that's not required to bring the tunnel up, it only needs to be able to establish in one direction.
Correct the phase2 subnet mismatch.
Steve
-
Thank you for your patience, Steve.
Sorry, there was a typo (copy and paste error). This is the current configurationpfsense site B:
phase1 - remote gateway 1.1.1.1/25
phase2 - local subnet 192.168.200.0/24, remote subnet 192.168.100.0/24pfsense site A:
phase1 - remote gateway 3.3.3.3/25
phase2 - local subnet 192.168.100.0/24, remote subnet 192.168.200.0/24I'm not able to start the iPSEC and this is what I see on site A pfsense GUI:
Thank you.
-
Ok, that should work as long as the identifiers match, which they may not because one side is behind NAT.
If you are using the default identifiers 'my IP address' and 'peer IP address' it will fail because site A will send 10.99.0.2 but the other side will see the IP as 3.3.3.3.
So make sure you are using matching identifiers. Set site A to use 'IP address' as it's own identifier and set 3.3.3.3.Check the ipsec logs at site B. You will probably see the expected errors for that:
https://docs.netgate.com/pfsense/en/latest/troubleshooting/ipsec-logs.html#phase-1-identifier-mismatchSteve
-
Trying to start the ipsec tunnel from the pfsense 10.99.0.2 on the left side (site A) to pfsense 3.3.3.3 and analysing the traffic with Wireshark I see that
without changing the identifier:
8003 2022-11-30 02:11:35.758047 3.3.3.1 3.3.3.3 ISAKMP 506 IKE_SA_INIT MID=00 Initiator Request
8004 2022-11-30 02:11:35.763770 3.3.3.1 3.3.3.3 ISAKMP 78 IKE_SA_INIT MID=00 Responder Responsechanging the identifier:
8003 2022-11-30 02:14:35.283948 3.3.3.1 3.3.3.3 ISAKMP 506 IKE_SA_INIT MID=00 Initiator Request
8004 2022-11-30 02:14:35.283970 3.3.3.1 3.3.3.3 ISAKMP 78 IKE_SA_INIT MID=00 Responder ResponseSince the IP 10.99.0.2 is behind NAT, I should use the "IP address" identifier, ok.
But why should I use the 3.3.3.3 and not the 1.1.1.1? This question is because 10.99.0.2 is behind the public IP 1.1.1.1 and because I read:"IP Address
A specific static and manually-entered IP address to be used as the identifier. One potential use for this is when the firewall is behind NAT where the real external IP address could be used in this field."Was it a typo?
Anyway, as you can see, in the schema there are two routers and they are running with NAT enabled...
Is the "IP address" identifier enough to bypass the NAT effects of both of them?Thank you.
-
Sorry, yes that was a typo. The IP address used for the identifier should be the local public IP. So the pfSense at site A should indeed use 1.1.1.1.
I was assuming that 3.3.3.3/25 is a public subnet here so that side is not behind NAT. Is that not the case?
Steve
-
Good morning Steve, in order to simplify your analysis I created a new GNS3 Lab simulating the real scenario.
In this schema you can see all the IP addresses (only two of them are public IPs) and all the involved instances .
Below you can find some important info:
- 10.99.0.0/24 is the transport network that you suggested to use;
- 192.168.118.0/24 and 192.168.120/24 are the LAN I would like to "join" using IPSEC VPN;
- you can ignore the dotted links since they are here only for management purposes;
- RouterA can ping RouterB and they have NAT enabled;
- pfsenseA can ping RouterB public IP;
- pfsenseB can ping RouterA public IP;
- in addition to the basic/standard IPSEC configuration, I set the identifiers as you suggested (on pfsenseA ipaddress id 192.168.122.230, on pfsenseB ipaddress id 192.168.122.205);
- when I try to start IPSEC tunnel from pfsenseA, no connection starts
- the IPSEC logs say that:
- this is what I see if I check the traffic using Wireshark on the WAN interface of routerB:
9 2022-11-30 14:43:44.663606 192.168.122.230 192.168.122.205 ISAKMP 506 IKE_SA_INIT MID=00 Initiator Request
10 2022-11-30 14:43:44.665168 192.168.122.205 192.168.122.230 ICMP 534 Destination unreachable (Port unreachable)and nothing else related to this kind of connection.
- No relevant traffic seems to be passed from RouterB to WAN interface of pfsenseB
It seems that the IPSEC traffic and port are not "passed" from RouterB to WAN interface of pfsenseB. I read a lot of things about IPSEC behind NAT, someone says that we should activate a port forwarding on the routers ( 192.168.122.230:500 > 10.99.0.2:500, 192.168.122.205:500 > 10.55.0.11:500) other people talks about NAT-T but I didn't understand when and where I should activated it. Someone says that also Peer identifier should be changed...
Could you please help me again to understand ?
Many thanks in advance for you patience,
Mauro -
Do you have a new diagram showing those subnets?
So 3.3.3.3/25 is not a public subnet?
If both sides are behind NAT you will need to forward the IPSec traffic through one of the external routers to pfSense in order to bring up the tunnel reliably. Without that you rely on both ends opening outbound states at the same time that match the incoming traffic which may or may not happen.
Steve
-
-
Ok, so is 10.55.0.0/24 at site B a public routed subnet there?
If not both sides are behind NAT and you will need to forward traffic in router A and/or B to establish the connection.
-
In your original diagram you have a /30 transport subnet bewteen the ISP and Router B and then a /25 behind Router B which looks like it would be a public subnet?
-
@stephenw10 said in pfSense and IPSEC lan to lan: a big doubt about the correct implementation:
Ok, so is 10.55.0.0/24 at site B a public routed subnet there?
Yes, it is :) in the real scenario it is a public routed subnet.
-
Ok, then you need to replicate that. pfSense B has a public IP and the tunnel should be using that directly, not the router B address.
-
I also note that the pfSense IP is 3.3.3.2 and you appear to have used 3.3.3.3 as the remote host IP at site A. Is that a typo?
-
@stephenw10 yes, it was a typo, but, please, refer only to the last schema I attached here :)
