Yes, but you cannot masquerade IPSec tunnels (don't mix that). If the tunnel starts on the machine which do masquerading you usally want that tunneled connections not to be masqueraded - so adapt the masqurading rules. Please note, that you must not masquerade IPSec traffic (proto 50/51).

Actually you can masquerade if you don't use AH (Authenticaiton Headers), some Crisco routers/etc have other features now that allow you do have NAT and IPSec.

I guess it would, but IPSec is somewhat more platt-form independed and my choice. With SuSE 7.0/7.1 it's easy to set up IPSec, just install freeswan.rpm (well, I'm not sure if that RPM is avialable for recent kernel updates, so you may get a problem here, check FTP server), edit ipsec.conf according to the documentation and run it :)

In theory if people adhere to the IPSec standards it's good, but many are adding weird extensions =(.

oki,

Steffen

-Kurt

* Tobias Gewinner wrote on Thu, Jun 21, 2001 at 00:16 +0200:

On Wed, Jun 20, 2001 at 10:22:12AM +0200, Schulz, Wolfgang wrote:

...

Thanks for your help! One more question regarding our configuration: I forgot to mention that we have in the internal nets private addresses which are masqueraded at the firewall. Due to different reasons we need the

This is exactly the same scenario that almost drove me crazy ;-), also with private networks behind the firewalls and masquerading to the outside.

This is no problem. To other private networks tunnel (w/o masq) your traffic, to the Internet masq your traffic. Allow UDP port 500-->port 500 and IP protocol 50,51 (don't intermix :)).

Maybe you have to set the routes manually? (ipsec eroute [???])

no, ipsec sets the routes for the other side of your tunnel automatically. If not, you have some misconfiguration :) In some cases IPSec routes a little bit different, i.e. you need a gateway entry always (even on ppp links, where you can "route add default ipppX" - but when useing IPSec you _have_ to specify the right gateway).

My exact problem was: The tunnel had been established but no packets have been forwarded through the tunnel at all.

So you see proto50 packets on the wire on both sides? Check the IPSec trouble-shooting document. First, I would start w/o firewalling and ping <peer> -I <my-internal-address> depending on your configuration. The most important point: keep always in mind what happens internally. The "follow" that way with some tools. i.e. frist check the incoming packet, the check the traffic on the ipsecX device (clear text), then the assigned phys. Device, i.e. eth0, expect proto 50 packets, then check phys. on the other side, the ipsec on the other side (expect clear text). The you know where you problem sits and you can fix it.

If you can establish a tunnel between the firewalls, you may have a routing problem or the firewall denies input from his partner's private subnet (as I wrote in my last reply).

Well, if firewall blocks you should get a log message. But I would suggest to open the peer IP completly while testing. Keep care that you log all denied packets! IPSec filtering isn't trival :) Packets pass the chains twice: first encrypted and second in clear, so you need at least two rules usually! Use tcpdump to see what happens. Check logs. If you get SA established on both sides, UDP 500, keys, config and handshaking are usually OK and fine. Don't try pinging from the gateway itself when having a single tunnel - this will not work. You may specify your internal IP (part of leftsubnet/rightsubnet) with -I option (just a hint :)). oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.