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/
> 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.How is your lan zone defined? You tried the netmask trick but that involves other problems I guess. Maybe you should let shorewall know that your lan zone is bigger than only 192.168.1.0/24. I think you could remove the routeback option for eth2 in the interfaces file and configure something like this: /etc/shorewall/hosts: lan eth2:192.168.0.0/16 routeback Regards, Simon ------------------------------------------------------------------------- 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/
Night Eagle wrote:>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.A couple of thoughts that come to mind. 1) What policies are set on the Pix ? Do they correctly send DMZ traffic from the clients via the VPN tunnel ? Do they allow the traffic through at the Pix end ? 2) You are trying to access IPs via the VPN that are in the same subnet as the Pix external interface, does the Pix try and route these directly itself ? That would seem a logical thing to expect, after all it isn''t normal to route packets to a locally connected subnet via a different gateway. Before getting too bogged down at the Shorewall end, have you checked that the packets are actually reaching the Shorewall machine ? Get out your favourite packet sniffer (I use wireshark) and see if you actually see packets coming out of the Pix internal interface that are destined for the DMZ. ------------------------------------------------------------------------- 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/