Unable to send traffic through IPsec site to site VPN even though tunnel is up

adamjoesbury

Hi There,

I have created a site to site IPsec VPN tunnel using a PFSense box at each end. I have successfully (I think!) configured the phase 1 and phase 2 sections and in the Status => IPsec page on both sides the tunnel is established and appears to be stable. I believe it is a relatively simple setup looking to make the LAN at Office A on 192.168.1.0/24 visible to the LAN at Office B on 192.168.3.0/24 and vice versa.

I have added an allow all IPsec rule on both sides:

IPv4 * * * * * * none Allow IPsec access

The problem I am having is that I can ping remote machines using their internal addresses from the other side of the tunnel but cannot seem to get any traffic flowing between the two other than ICMP.

When I try and initiate a PuTTY SSH connection from a machine in Office A to one in Office B, I can see in the firewall logs at Office B that the traffic is allowed. I can however also see a corresponding row in Office A's firewall suggesting that the traffic in the same direction is blocked due to the default LAN deny rule.

On Office B's firewall:
Pass Sep 14 14:59:35 IPsec  Allow IPsec access (1505160500)   192.168.1.10:57898   192.168.3.10:22 TCP:S

On Office A's firewall:
Block Sep 14 15:00:52 LAN Default deny rule IPv4 (1000000103)   192.168.1.10:57883   192.168.3.10:22 TCP:RA

If this traffic is blocked by Office A, how did the connection get to Office B?
Why is it showing as LAN interface at Office A and not IPsec?

I have automatic outbound NAT VPN rules enabled on both sides and each side only has one WAN connection with its own gateway.

I'd really appreciate some pointers as to what steps I could take to find out where my issue is. I'll provide any more info as required in terms of the setup of the tunnel but with the status showing established I am assuming the problem is not with the tunnel itself?

Thanks to all for any assistance!

adamjoesbury

The issue was down to a bug with the modem from our ISP fragmenting packets. New ISP, problem solved!