pfSense and IPSEC lan to lan: a big doubt about the correct implementation
-
@mauro-tridici
When you setup a conventional IPSec in tunnel mode, you state the local and remote network, which should be connected together, in the phase 2 on both sites.
The routing is then done by the pfSense kernel. There is no need to add further routes for that. -
@viragomann thank you for your reply.
Could you please explain to me how does a host on LAN1 know what is the right route to a host on LAN2 without setting the respective gateways as written in my previous post?
Is there a document you suggest I read to understand how a LAN to LAN VPN works? Can you detail your answer further? I thank you very much.
Mauro
-
@mauro-tridici
Both VPN endpoints have to be the default gateway in their respective local network, of course.
Isn't this the case in your setup?So the requesting device is sending packets destined to the remote site to its default gateway, because the destination IP is outside of its subnet. The same is true to the response packets on the remote site.
-
At this moment, both LAN1 and LAN2 have their respective gateways (in each of their respective locations) in order to reach internet.
But now we need to create a tunnel between them. So, how can Lan1 and Lan2 reach internet if we set the new gateways?
Sorry if it Is a stupid question.
Thanks -
@mauro-tridici
It's not neat to configure a site to site VPN not on the default gateway in the LAN at all.
So why want you do this? Why are the pfSenes not the default gateway? Why don't you run the VPNs on the default gateway?You can do that though, but it needs a bigger effort:
Put the VPN endpoints into separate network segments on both site (transit networks). This can also be done with VLANs and leave them on the same hardware networks.
The pfSense must logically be disconnected from the LANs.Then you have to add static routes to all four devices:
Loc1:
pfSense: 192.168.10.0/24 > default gateway (the transit network IP either)
Gateway: 192.168.20.0/24 > pfSenseLoc1:
pfSense: 192.168.20.0/24 > default gateway (the transit network IP either)
Gateway: 192.168.10.0/24 > pfSenseEnjoy.
-
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
