hi. we are facing problems in a particular setup we need to implement. We have two offices we want to connect via ipsec, behind them the same subnet scheme for the internal LANs (192.168.0.x). In my office, on one side of the connection, i''m using shorewall 2.4.3 with kernel 2.6.11-hardened-smp, ipsec-policy match patches to netfilter, and no netmap patch. Eth3/eth4 are interfaces connected to 2 xDSL providers, balanced in /etc/shorewall/providers; the ipsec tunnel btw if forced to go on eth4 by tcrules. this is my side: LAN (192.168.0.0/24) ---> br0 [FIREWALL] <--- eth3/eth4 INTERNET The other side is a netscreen 5 GT (ipsec w/tunnel mode) The ipsec handshake is working fine. We want to rewrite the subnet in my office to be seen from the counterpart by 192.168.255.x, without using the netmap module. issues here: - kernel is 2.6, so ipsec has the same physical interface as the external - using proxyarp/subnetting, we go out from the firewall to the wan without any respect of whom we connect to; we want, instead, to show only the .255.x subnet INSIDE the ipsec tunnel interface to the other office (the rest of the world is masqueraded and balanced on the 2 dsl lines) - i have no control over the other office''s configuration. but i know ipsec works. I hope i''ve kept things clear. Am I missing something here? there''s a clean way to achieve this? Thanks a lot. -- Giovanni Ferri __________________________________ System Administrator E-mail: giovanni@fonderiadigitale.it Ph. +393280643354 PGP Fingerprint: 40F4 AE1E A2CC 95B0 4025 E78E FFAC 9EC2 1F2E 5B78 __________________________________
On Thursday 12 January 2006 07:00, Giovanni Ferri wrote: DISCLAIMER: I have no idea if this will work but it''s the only option that I can come up with. Other subscribers are welcome to offer suggestions.> > We want to rewrite the subnet in my office to be seen from the counterpart > by 192.168.255.x, without using the netmap module.That''s only half the problem -- you also need the remote subnet to be seen as 192.168.yyy.x to your local hosts. So the Netscreen is going to have to do DNAT of the decrypted traffic (I understand that you don''t control that box but there is no way to do this magic without both gateways participating -- see the Shorewall NETMAP article for an explaination). Be sure to set up IPSEC so that traffic from your gateway to the remote subnet matches a negotiated SA. Then in /etc/shorewall/masq: <external if>:192.168.yyy.0/24 192.168.0.0/24 <external ip> Yes --- So at the other end, all traffic from your subnet will be addressed to 192.168.yyy.x and the source IP will be the external IP address of your firewall. Note that means that your local network can connect to the remote hosts but not vice versa. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
Alle 16:25, giovedì 12 gennaio 2006, Tom Eastep ha scritto: Thanks for replying.> That''s only half the problem -- you also need the remote subnet to be seenas> 192.168.yyy.x to your local hosts. So the Netscreen is going to have to do > DNAT of the decrypted traffic (I understand that you don''t control that box > but there is no way to do this magic without both gateways participating -- > see the Shorewall NETMAP article for an explaination). > > Be sure to set up IPSEC so that traffic from your gateway to the remotesubnet> matches a negotiated SA. Then in /etc/shorewall/masq: > > <external if>:192.168.yyy.0/24 192.168.0.0/24 <external ip>Yes> So at the other end, all traffic from your subnet will be addressed to > 192.168.yyy.x and the source IP will be the external IP address of your > firewall. > > Note that means that your local network can connect to the remote hosts but > not vice versa.Yes, This is already set up: the netscreen is configured to reference my side as ''192.168.255.x''. My wish (or perhaps, my fault) was to reference them as .255 myself in my firewall, so doing all the dirty work inhouse. -- Giovanni Ferri __________________________________ System Administrator E-mail: giovanni@fonderiadigitale.it Ph. +393280643354 PGP Fingerprint: 40F4 AE1E A2CC 95B0 4025 E78E FFAC 9EC2 1F2E 5B78 __________________________________ ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id865&op=click