Multiple Gateways in DMZ
-
Hi All,
I'm trying to revise a network with an old Linux FW which has a proxy arp'd setup to provide public IPs to servers in the DMZ.I want to replace this setup with PFSense and use 1:1 NAT instead of proxy arp, and in order to reduce impact I have setup a 2nd PFsense Firewall and am migrating servers over slowly.
The PFSense FW is using VIPs with 1:1 NAT on a private range.
The problem I have is that our remote office connects to us via a TUN OpenVPN tunnel, which has a route for my DMZ address range pushed to it through the tunnel - the clients cannot access anything that is hosted by the 2nd firewall is not accessible via it's public address.
Could anyone suggest what's going wrong here? I've attached a (basic) diagram of my setup.
-
Hi All,
I'm trying to revise a network with an old Linux FW which has a proxy arp'd setup to provide public IPs to servers in the DMZ.I want to replace this setup with PFSense and use 1:1 NAT instead of proxy arp, and in order to reduce impact I have setup a 2nd PFsense Firewall and am migrating servers over slowly.
The PFSense FW is using VIPs with 1:1 NAT on a private range.
The problem I have is that our remote office connects to us via a TUN OpenVPN tunnel, which has a route for my DMZ address range pushed to it through the tunnel - the clients cannot access anything that is hosted by the 2nd firewall is not accessible via it's public address.
Could anyone suggest what's going wrong here? I've attached a (basic) diagram of my setup.
I believe the problem is with the routing .
8.8.8.203 should have a static route to know how to reach 10.50.30.1/24 through 8.8.8.204 which is directly connected because they are on the same subnet (/24)Try to ping from the remote Ovpn network the IP's you want to reach ( ex. 8.8.8.204 and then 10.50.30.1 ), if it fails then traceroute to see where are the packets going. On the second pfSense yu have in Diagnostics - packet capture - usefull to debug this kind of problems.
Check this diagram https://www.secure-computing.net/wiki/index.php/Graph to understand gateways and routes in a similar OVPN setup.
Adrian
-
Thanks for your reply - the 10.50.30.0/24 addresses are accessible from everywhere - the problem is that some users want to use the WAN addresses (for testing websites), and anything that is connected to the 2nd firewall is not accessible via our remote office.
I managed to temporarily resolve this by removing the OpenVPN route to push 8.8.8.0/24 down the tunnel, and manually specified /32 routes for individual servers, but this affected other areas of the business.
The issue I can see is that when I log into the OpenVPN PFSense box (8.8.8.203) and do a traceroute to one of the VIPs hosted by the 2nd firewall (8.8.8.204), it sends it down the default route of the OpenVPN box even though it's in the same subnet.
The OpenVPN box can ping the VIP OK, but anything that's on it's TUN tunnel can't.
traceroute to 8.8.8.242 (8.8.8.242), 64 hops max, 40 byte packets
1 (8.8.8.1) 608.339 ms 0.217 ms 0.106 ms
2 8.8.8.242 (8.8.8.242) 734.557 ms 0.290 ms 0.270 ms
3 8.8.8.242 (8.8.8.242) 0.573 ms 0.341 ms 0.391 ms