[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: esp disappear trought my debian firewall



On Tue, 2003-02-04 at 01:19, Jeremy T. Bouse wrote:
> 	I'm not certain but I don't recall that VPNs which go through
> NAT really like that as it messes with the headers usually... For this
> reason I usually run the VPN gateway from the firewall/gateway machine
> rather than from a machine behind the NAT...
> 
> 	As for iptables rules which I use, I typically have it allowing
> 500/UDP traffic to the VPN machine for IKE, along with both protocols 50
> (ESP) and 51 (AH) allowed for traditional IPSec solutions... If you have
> a GRE solution you may need to include the GRE protocol 47 as well... I
> also believe some M$ VPN solutions require other channels to be open but
> these work for most IPSec/VPN solutions I've had experience with...

If you talk about GRE and ipsec, the gre traffic will be encrypted and
so should not go trough the firewall.

Microsoft vpn solution is typically PPTP and is not a recommended
solution if possible for security reason (depending on the settings, but
there is a cryptographic flaw in PPTP authentication).

Generally speaking, nating IPSec traffic is not a good idea: the main
problems are identity issues at both IKE and IPSec level as well as the
fact that if you use AH (which cover the external ip packet), as the
packet changes by NAT, this wont work. There are ways, but this is not
the ideal.


For the particular problem, if you dont see the packet at all, this is a
firewalling problem. Could you describe your rules and give out more
details (versions etc..)
> 
> 	If your VPN gateway is also your firewall then these rules
> would need only be applied to your INCOMING interfaces usually, in
> attempting to use a VPN gateway inside your network I would be checking
> all three (INPUT on both external & internal interfaces, FORWARD and
> OUTPUT again on both external & internal)... It will most definately be
> a trick to catch as the VPN itself will be modifing the packets as will
> the NAT making the task that much harder... If you can I'd honestly
> recommend moving it to the firewall machine itself from my networking
> experience.
> 
> 	Respectfully,
> 	Jeremy T. Bouse
> 
> On Mon, Feb 03, 2003 at 01:35:28PM +0100, Esteban wrote:
> > Hello, all. 
> > I'm having problems to get my vpn go throught my Linux gateway. The
> > beginning of my vpn tunnel is inside my local network, and its
> > destination is outside, on the internet :
> > 
> >  VPN1 (local network)
> >   |
> >   |
> >   |
> > Linux GW
> >   |
> >   |
> >   |
> > -------
> > internet
> > -------
> >   |
> >   |
> >   |
> >  VPN2
> > 
> > 
> > The problem comes from my Linux GW, which loose my ESP packets.
> > When an ESP packets comes from VPN1 with destination VPN2, it goes
> > throught my LINUX GW. I can see the packet going throught iptables. I
> > see it on the INPUT NAT chain, on the FORWARD filter chain, and it goes
> > throught the last POSTROUTING NAT chain, where it is SNAT to go on the
> > internet. But I can't see it on my external interface with tcpdump. The
> > packet seem to disappear between the lat POSTROUTING chain and my
> > interface. 
> > 
> > When I LOG it on the last POST routing chain, I have the
> > following LOG message, just before the packet being SNAT:
> > 
> > IN= OUT=eth1 SRC=10.0.0.2 DST=193.x.x.x LEN=128 TOS=0x00 TTL=254
> > ID=29906 PROTO=ESP SPI=0xdaabbc8c
> > 
> > where eth1 is my external interface.
> > 
> > In the other side, when an ESP packet comes from VPN2 with destination
> > my Linux GW, I try to DNAT it to my VPN1. But same thing, I can see it
> > with tcpdump on my external interface, but I still can't see it in the
> > first NAT PREROUTING chain. ...
> > 
> > My Linux GW is a debian with 2.4.19-grsec kernel.
> > 
> > I really don't know what's happening. Does anobody have already seen
> > this problem ? Tkx
> > 
> > --
> > Esteban
> > 
> > 
> > -- 
> > To UNSUBSCRIBE, email to debian-firewall-request@lists.debian.org
> > with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
-- 

-> Jean-Francois Dive
--> jef@linuxbe.org

  There is no such thing as randomness.  Only order of infinite
  complexity. - Marquis de LaPlace - deterministic Principles - 




Reply to: