On Mon, Feb 09, 2004 at 07:43:37PM +1100, Matthew Palmer wrote: > On Mon, Feb 09, 2004 at 04:56:40PM +1100, Patrick Lesslie wrote: > > I'm trying to get freeswan running on debian stable. The trouble is > > there is a cisco router doing DSL and doing NAT to the debian box, > > which also masquerades to another internal network. > > > > Is anyone successfully running freeswan through a router? > > Yes, but it's a hack. > > The problem is that IPSec requires that both source and destination ports for > an IKE connection be UDP 500. Now, with a sane NAT engine (*cough* iptables > *cough*) this works, because it tries to keep ports the same as much as > possible. However, Ciscos don't - you'll get a source port out of the NAT > router in the high range, which your other end will take one look at and go > "screw that and the horse it rode in on". > > The way to fix it is to configure the Cisco to do port forwarding of UDP 500 to > your IPSec machine inside, and initiate the connection from outside to the > public interface. That way both source and dest port will be 500, and your > IPSec boxes are none the wiser.
I think I see. The source port gets preserved if the packet is explicitly port-forwarded.. So at the moment it's configured to do a source NAT sending packets addressed to 203.x.x.1 to 192.168.1.2 (debian) and the packets appear to be from the router (192.168.1.1) instead of from the remote IP, which means that UDP 500 packets to the external IP do get to debian, but presumably with the source ports altered for some Cisco reason, and I should also port-forward UDP 500. Do I also need NAT-T just to get the packets to be UDP packets, or is IKE always like that, and I still have to get the router to forward the ESP and GRE packets? > Short of making NAT traversal work (and it's a PITA, if only by the fact that > there's several different "standards" for doing it), this is the best way if > you've got to make it work over a brain-dead NAT device. Naturally, this way > won't work for multiple separate VPN endpoints behind your NAT device, but it's > better than nothing. I don't mind if they can only access one machine, so long as it runs windows and is on the internal lan ;-P But you didn't mean that there can only be one person coming in at once did you? After all I want VPN connections flying all over the place... > Anyway, if you've got VPN connections flying all over the > place, then the network design probably needs to be rethought a little, to > accomodate those sorts of things more gracefully... That would be excellent. I was wondering though, how to do it. I thought perhaps I might be able to get the Cisco into bridging mode, or just replace it with a brick, I mean a bridge (I guess?). That way the diagrams would be simpler, and I could talk using the external IP. I guess that means running pppoe as well. Since the cisco has 4 external IPs, it would be great to bridge at least one of them, so that there were sort of two independent external interfaces, debian on one and cisco on the others. Later with another box I'd like to be able to split the internal firewall and the freeswan one, in which case I suppose freeswan should go on an independently strong machine in a demilitarised zone. Then IPtables would just have to allow ipsec through, and if someone broke the freeswan machine, they could just vpn into the LAN :-) There actually doesn't seem to be much need for the router's fancy features above being a bridge anyway, now that the linux box is running the firewall, so swapping it out might be feasible if that were the best way to go. I still need NAT traversal anyway, going to try superfreeswan, because there might be NAT going on at the road warrior end ... The more I re-read this, the less it makes sense ;-} Thanks for the tips, Patrick -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
