I am experiencing an intersting problem with my shorewall router/firewall and I'm hoping someone here might be able to help me diagnose and fix the problem.
I have a mostly normal setup: a linux computer running shorewall (v3.4.3) that has three interfaces. The three interfaces correspond to net (eth5), dmz (eth4), and lan (eth2) zones. The lan zone can connect to dmz and net. dmz can only connect to net. This all works great thanks to shorewall. The wrinkle is that we have a Cisco PIX for VPN access to the lan zone from outside the firewall. Problem is that clients connecting through that device can only access the lan zone, not the dmz zone. The external interface of the PIX is in the dmz zone (10.0.1.2/24), and accessible from the net via a set of DNAT rules. The internal interface of the PIX is in the lan zone (192.168.1.4/24), so when a client connects, they are tunnelled through and appear to be another client in the lan zone, albeit with an address for a different network. When a client connects to the PIX using the cisco VPN client, the VPN tunnel endpoint is assigned an address 192.168.2.X (by the PIX). Initially we had a problem where return packets were not making it back to the PIX. We solved this by adding a static ip route (192.168.2.0/24 via 192.168.1.4 dev eth2) and adding "routeback" option in interfaces file for eth2. This made it possible for our VPN clients to access devices in the lan zone, and there was some rejoicing. The one problem that still remains is that those VPN tunneled clients cannot reach the machines in the DMZ zone, even though the rules and policy would seem to allow that traffic. I'd really like to know what to tweak that would allow those VPN clients to connect to DMZ servers. My theory is that we need some sort of additional route or routing option to enable this path, just as we had to add a static route and routeback option to get the return packets back to that 192.168.1.4 interface. I would think that our static route would do the trick to get packets destined back to the 192.168.2.X VPN tunnel endpoint back over to 192.168.1.4, but that does not seem to be the case. One thing I did try without success was to narrow the netmask on eth2 to 255.255.252.0 so it would include both 192.168.1.X and 192.168.2.X networks, but still was not able to establish connections in this path. Anyone have any ideas on how I might resolve this? It's really got me baffled. thanks for you consideration, Jimmy ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
