pfSense and IPSEC lan to lan: a big doubt about the correct implementation
-
You can also add static routes to the LAN hosts directly but you would have to do so on each hosts that required access to the VPN. Using transit networks is the cleaner solution.
Steve
-
@viragomann @stephenw10 many thanks for your help.
However, I should correct what I wrote in the previous message by adding some information.
In order to make it easier to interact with you, I have prepared a diagram summarizing the scenario for location A and location B.
Location B
As you can see, in Location B there is already a router and a virtual pfsense instance (which performs the gateway function for the LAN2 network).
So, in Location B, I could use the same instance of pfsense as the endpoint for the lan to lan VPN just over IPSEC, right?
Can you confirm to me that such intervention should not create disruption to the other existing networks?Location A
As you can see, there is no instance of pfsense in Location A.
To complete the implementation of the lan to lan VPN, I would have to create a new instance of pfsense and fake point to the gateway/router.In your opinion, what would be the easiest and fastest configuration/solution to achieve the end goal without disrupting the services currently in production?
I thank you in advance.
Have a nice day,
Mauro -
Yes, at site B you can use the existing pfSense install as the IPSec endpoint.
Only traffic defined in the IPSec policy can be affected by that so if it only covers 192.168.100.X to 192.168.200.X it won't affect anything else.
The least disruptive way to complete the tunnel is to add a new pfSense instance in a separate transport subnet at site A. Then add routes to it for 192.168.200.0/24.
Steve
-
Hello Stephen, welcome back :)
Thank you again for your reply.So, if I'm not wrong (and if I correctly understood the meaning of "transport subnet"), the final scenario should be the one in the following schema, right?
Regarding the static route, I think I should add it to the virtual router as mentioned in the schema.
Please, correct it if it is wrong.
Thanks,
Mauro -
If you're able to do that it will certainly work fine because pfSense will be the default gateway for hosts on both sides. But making that change is quite disruptive at site A. You don't have to do that. Instead you can attach pfSense to a new interface on the router at site A without making changes to the existing interfaces and subnets. Only pfSense exists in that subnet and you add static routes to the existing router so traffic for the remote subnet goes that way. Like:
-
@stephenw10 thanks again for your support and the attached schema.
So, if I'm not wrong, the final schema should be the following one, right?
Kind Regards,
Mauro -
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
-
