pfSense and IPSEC lan to lan: a big doubt about the correct implementation
-
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 :)
-
@stephenw10 mmmmmc ok, you are right. thank you.
Do you know how can I do it in GNS3 first?
Thanks,
Mauro -
Well you would need to add 10.55.0.0/24 as a static route via Router B. Then in router B configure it not to NAT that traffic.
Or just remove router B entirely and put 192.168.122.205 on pfSense B directly.
-
@stephenw10 many thanks again for your patience.
Now the schema is the following one:
And it seems that something is working (thank you Steve).
At this moment, there is no traffic forward rule on RouterA.
The IPSEC tunnel is started from pfsenseA (I only added the identifier as you suggested)Now the last step before closing this case.
PC1 and PC2 are not able to ping each other. IPSEC firewall rules allow any traffic to any hosts, but there is this last problem.On every pfsense interfaces there is a single rule that allows any traffic to any hosts and ports.
What do you think I'm missing ?
-
Ok so the tunnel is up at P1 and P2. The subnets it's carrying look correct.
The traffic counters show 0 packets in or out. Does it show that at both ends?
I would guess that you are missing the route on Router A to 192.168.120.0/24 via pfSense A.
Client at site B should still be able to send though and that should match the policy and be sent over the tunnel.
-
Unfortunately, the route on router A has been already set.
-
Ok, then check both ends, do the traffic counters still show as 0 after trying to ping in both directions?
How exactly are you running that ping?
Do you see anything blocked in the firewall logs?
-
@stephenw10 said in pfSense and IPSEC lan to lan: a big doubt about the correct implementation:
Ok, then check both ends, do the traffic counters still show as 0 after trying to ping in both directions?
yes, 0 stats on both the ends
How exactly are you running that ping?
I'm executing ping from the VPCS on the left of the schema (192.168.118.10) to the VPCS on the right (192.168.120.10) and viceversa
Do you see anything blocked in the firewall logs?
During the last attempts, it seems that nothing have been blocked but I will check again soon
-
The other thing to check is the state table in Diag > States. You should see states on the LAN and IPSec interfaces for the pings on each side.
At site B there is really nothing to stop IPSec at least sending pings from 192.168.120.10 to 192.168.118.10 over the tunnel.
At site A there are other things that could be preventing it. -
Ok, these are the states for the pfsenseA
and these are the states for the pfsenseB
Question: on the Router A I created a route 192.168.120.0/24 > 10.99.0.2.
Do I need to create a route rule also on pfsense A ? something like that: 192.168.118.0/24 > 10.99.0.1? -
I see no icmp states at all between the two subnets in either of those tables. Were the pings running?
You should not need to a route back on pfSense A because Router A is the default route there. (Or at least it should be!)
-
@stephenw10 yes, the pings are running and I'm making some tests on both the directions.
I checked again the firewall logs. no rule is blocking the traffic.
I'm trying to understand where is the error -
If there are still no icmp states then either there are firewall rules blocking that traffic or the pings never arrive at pfSense. A pcap on the pfSense B em2 interface should show that.
-
VPCS on the left can ping every hosts on the schema (except the 192.168.120.1)
VPCs on the left is not able to ping 192.168.120.0/24VPCS on the right can ping every hosts on the schema (except the 10.99.0.0/24)
VPCs on the left is not able to ping 192.168.118.0/24If I'm not wrong, it seems that the ping traffic is not passing through the tunnel.
Sorry for this stupid information... -
@stephenw10 said in pfSense and IPSEC lan to lan: a big doubt about the correct implementation:
If there are still no icmp states then either there are firewall rules blocking that traffic or the pings never arrive at pfSense. A pcap on the pfSense B em2 interface should show that.
I'm going to check this. I will let you know
-
@stephenw10 said in pfSense and IPSEC lan to lan: a big doubt about the correct implementation:
If there are still no icmp states then either there are firewall rules blocking that traffic or the pings never arrive at pfSense. A pcap on the pfSense B em2 interface should show that.
pcap on pfsense B em2 interface is completely blank/empty
-
Then the client PC there is not attached to em2 as it shows in the disagram or it is sending pings some other way, it has the wrong default route.
-
VPCS on the left:
VPCS> show
NAME IP/MASK GATEWAY MAC LPORT RHOST:PORT
VPCS1 192.168.118.10/24 192.168.118.1 00:50:79:66:68:01 20096 127.0.0.1:20097
fe80::250:79ff:fe66:6801/64VPCs on the right:
VPCS> show
NAME IP/MASK GATEWAY MAC LPORT RHOST:PORT
VPCS1 192.168.120.10/24 192.168.120.1 00:50:79:66:68:00 20098 127.0.0.1:20099
fe80::250:79ff:fe66:6800/64Both the client PC an reach internet and other machines in the schema
For example, the client PC on the left:
VPCS> ping www.google.it
www.google.it resolved to 142.250.184.3584 bytes from 142.250.184.35 icmp_seq=1 ttl=126 time=22.655 ms
^C
VPCS> ping 10.99.0.284 bytes from 10.99.0.2 icmp_seq=1 ttl=63 time=3.166 ms
^C
VPCS> ping 10.99.0.184 bytes from 10.99.0.1 icmp_seq=1 ttl=64 time=1.025 ms
^C
VPCS> ping 192.168.122.18084 bytes from 192.168.122.180 icmp_seq=1 ttl=63 time=2.851 ms
But if I try to make a ping from one client PC to the other one the pcap is empty.
