Site-to-Site OpenVPN tunnel UP; routes exist, unable to pass traffic (SOLVED)
-
I've been tasked with converting our tunnels from IPSec to OpenVPN; one set of sites is already using an OpenVPN site-to-site tunnel, I'm trying to setup the next site based on that configuration and I'm running into a wall.
I've setup the Site-to-Site (Shared Key) Server (Site B) and Client (Site C) and the tunnel comes up without a problem. From Site C, I can ping both internal interfaces of the C-B ovpn tunnel, from Site B I can ping both internal interfaces of the C-B ovpn tunnel, however I cannot get traffic to pass into the remote subnets. Firewall rules for LAN and OpenVPN on both sides permit at least ICMP, if not any. Additionally, if I setup a continuous ping from a workstation on each subnet to the opposite workstation, then perform captures on the openvpn interfaces, I only see icmp requests from Site C headed to Site B. I do not see requests from Site B, unless I'm pinging the interfaces inside the ovpn tunnel.
I think traffic from Site C is being properly routed into the ovpn tunnel, but I'm not sure that Site B is properly routing, even through the route properly appears in the routing table.
Outbound NAT is configured for Automatic on all three devices.
[Edit] Correction in the diagram above, the existing OpenVPN tunnel should read 'from B to A' as B is the client, and A is the server.
Any feedback would be greatly appreciated.
-ct
-
On site A and site B LANs you show netmask of /16 - but the pfSense interface addresses are shown as /24 and /22
That will certainly mean that traffic from some LAN devices won't find its way.
The other numbers look OK, but personally for simplicity so that mere mortals can quickly check the network, I would allocate /24 on the OpenVPN links - you have a /29 and a /30, both of which should work, but in future people will always be wondering why one is /29 and the other is /30. -
Phil,
1. The pfSense interfaces are subnets carved out of the supernet; we have a lot of subnets behind each firewall.
2. I'm not sure why there is a /29 on the existing OpenVPN tunnel, I will change it to a /30 in the future.Additionally, my issue is now resolved. The issue was that the server side of the tunnel (Site B) was not properly routing the traffic, even though the proper routes were there. Rebooting the pfSense box appears to have fixed it. On that note, I'm working on another tunnel, and I've run into the same issue, is there ANY way to restart specific components of pfSense that would kick-start the routing system without having to completely reboot my production firewall?
-ct