RE: [OT] Was: ESP does not hit the nat table

RE: [OT] Was: ESP does not hit the nat table

[Jason Opperisano]

> Hi all,
> Thanks for the reply, I know I messed up the iptables syntax - I did not include the chain...
>
> My main problem however was that ESP packets do not hit the nat table, but it does traverse mangle/filter table. Is this normal? I am mainly looking at SNAT/MASQUERADING ipsec traffic and I am not able to find any documentation on doing this, especially since there is no point in putting a "iptables -t nat -A PREROUTING -p 50 -j SNAT --to-source <me>". -p 50 means ESP as you can already guess.
> Am I missing something here? How do I masquerade ipsec traffic? (assuming my ipsec-VPN client/server is fine with it...)

it would be helpful if you

a) posted your rules (iptables -vxnL && iptables -vxnL -t nat && iptables -vxnL -t mangle)
b) explained what you're trying to do specifically
c) describe how you're testing

as far as the generic "can i nat ESP traffic with iptables" the answer is "surely."  i do it on one of my gateways where it's necessary for the LAN behind the gateway to appear differently when it goes through the VPN tunnel.

if i had to take a stab in the dark as to why you're having trouble--i would say that it's related to the fact that the outbound interface of your IPSec traffic needs to be specified as "-o ipsec0" (or whatever number your actual ipsec interface is), not ethX...

you *did* say you were using frees/wan, right?

-j

Re: [OT] Was: ESP does not hit the nat table

[Antony Stone]

On Tuesday 03 August 2004 1:42 pm, Jason Opperisano wrote:

> > My main problem however was that ESP packets do not hit the nat table,
> > but it does traverse mangle/filter table. Is this normal? I am mainly
> > looking at SNAT/MASQUERADING ipsec traffic and I am not able to find any
> > documentation on doing this, especially since there is no point in
> > putting a "iptables -t nat -A PREROUTING -p 50 -j SNAT --to-source <me>".
> > -p 50 means ESP as you can already guess. Am I missing something here?
> > How do I masquerade ipsec traffic? (assuming my ipsec-VPN client/server
> > is fine with it...)
>
> if i had to take a stab in the dark as to why you're having trouble--i
> would say that it's related to the fact that the outbound interface of your
> IPSec traffic needs to be specified as "-o ipsec0" (or whatever number your
> actual ipsec interface is), not ethX...

Actually, I thought the ipsecX interface was used for the plaintext traffic, 
and ethX was used for the encrypted stream?

My model of frees/wan and netfilter is:
 - encrypted packet arrives on ethX, passes through INPUT to local klips 
process
 - decrypted packet appears on ipsecX pseudo-interface, passes through 
FORWARD, and goes to local client

 - plaintext reply data comes in on standard ethernet from local network, gets 
FORWARDed to ipsecX
 - ipsecX has local process listening, captures plaintext and encrypts it
 - encrypted packet getnerated by local process, passes through OUTPUT and 
exists via ethX

Therefore I believe the TCP/UDP/ICMP traffic etc would be going in/out via 
ipsecX, whereas the ESP traffic will be going in/out via ethX.

Regards,

Antony.

-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

                                                     Please reply to the list;
                                                           please don't CC me.

Re: [OT] Was: ESP does not hit the nat table

[Ming-Ching Tiew]

Did you patch the kernel using NAT-T patch ? And 
did you turn on the nat_traversal ?

It happens to my system too where I have
nat-t patch, but nat_traversal is disabled (default) in 
freeswan configuration, then I put in a rule like this :-

     iptables -t nat -I PREROUTING -p esp

When I list the rule, I can't see any packet going thru' it.

Regards.

RE: [OT] Was: ESP does not hit the nat table

[Kashyap Ashwin]

I am sorry, this was my mistake, man page:

nat    This table is consulted when a packet that creates a new connec-
       tion is encountered.  It consists of three built-ins: PREROUTING
       (for  altering  packets  as  soon  as they come in), OUTPUT (for
       altering  locally-generated   packets   before   routing),   and
       POSTROUTING  (for altering packets as they are about to go out).


This is what happened:
	1. I put a ACCEPT rule in PREROUTING for ESP traffic when client
connects. There is also MASQUERADE rule in the POSTROUTING chain.
	2. The client can now do ipsec vpn
	3. The client logs out and I remove the ACCEPT rule. There is
catch-all DROP rule in the PREROUTING chain. I was expecting the ESP
"connection" to be terminated.
	4. Since the ESP "connection" is already in established state,
later packets never hit the catch-all DROP rule in the PREROUTING chain.

	5. The client is happy, since he gets free access:)

I just put some rules in the filter table, FORWARD chain (each and every
packet hits this). Things seem to work OK.

Thanks for all the replies!
Ashwin


-----Original Message-----
From: netfilter-admin@lists.netfilter.org
[mailto:netfilter-admin@lists.netfilter.org] On Behalf Of Ming-Ching
Tiew
Sent: Thursday, August 05, 2004 12:36 AM
To: netfilter@lists.netfilter.org
Subject: Re: [OT] Was: ESP does not hit the nat table


Did you patch the kernel using NAT-T patch ? And 
did you turn on the nat_traversal ?

It happens to my system too where I have
nat-t patch, but nat_traversal is disabled (default) in 
freeswan configuration, then I put in a rule like this :-

     iptables -t nat -I PREROUTING -p esp

When I list the rule, I can't see any packet going thru' it.

Regards.

[OT] Was: ESP does not hit the nat table

[Kashyap Ashwin]

[-- Attachment #1: Type: text/plain, Size: 994 bytes --]

Hi all,

Thanks for the reply, I know I messed up the iptables syntax - I did not
include the chain... 

 

My main problem however was that ESP packets do not hit the nat table,
but it does traverse mangle/filter table. Is this normal? I am mainly
looking at SNAT/MASQUERADING ipsec traffic and I am not able to find any
documentation on doing this, especially since there is no point in
putting a "iptables -t nat -A PREROUTING -p 50 -j SNAT --to-source
<me>". -p 50 means ESP as you can already guess. 

Am I missing something here? How do I masquerade ipsec traffic?
(assuming my ipsec-VPN client/server is fine with it...)

 

Thanks!

Ashwin

 

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~            \|/ ____ \|/ 
Ashwin Kashyap                                   @~/ ,. \~@ 
Member Technical Staff                          /_( \__/ )_\ 
Thomson - Corporate Research                       \__U_/ 
                                                Don't Panic!

 


[-- Attachment #2: Type: text/html, Size: 4504 bytes --]

RE: ESP does not hit the nat table

[Jason Opperisano]

> iptables -t nat -j DROP
>
> Will not block ESP traffic.

It's not a valid command, either.  In addition to specifying the table (-t nat) to act upon, you also need to specify a command and a chain to operate on; i.e.,

	iptables -t nat -A PREROUTING -j DROP

Not that I'm recommending the above rule, but it'll sure drop some traffic...

> On the other hand
>
> iptables -t filter -p 50 -j DROP
>
> will block ESP traffic.

Nope...

	iptables -A FORWARD -p 50 -j DROP
Or
	iptables -A INPUT -p 50 -j DROP
Or
	iptables -A OUTPUT -p 50 -j DROP

("-t filter" is assumed if no "-t" is specified)

<OT>
 Where is the new-found obsession with dropping packets in the NAT table coming from?
</OT>

-j

Re: [OT] Was: ESP does not hit the nat table

[Antony Stone]

On Sunday 01 August 2004 8:03 pm, Jason Opperisano wrote:

> <OT>
>  Where is the new-found obsession with dropping packets in the NAT table
> coming from? </OT>

Indeed.   A few people here have commented recently that they prefer dropping 
stuff in the PREROUTING nat table instead of waiting until it hits INPUT or 
FORWARD, for things like spoofed packets or invalid TCP flag combinations.

I guess dropping things in nat is okay in exceptional circumstances, but I 
hardly think the efficiency boost of dropping in nat instead of waiting until 
the first filter table is reached makes any noticeable difference, and I 
still advocate doing address translation in the nat tables, filtering 
operations in the filter tables, and anything else in the mangle tables.

Just so long as you remember never to set a default policy other than ACCEPT 
on any nat or mangle tables.....

Regards,

Antony.

-- 
I own three Windows books, published by O'Reilly.   They are "Windows 
Annoyances", "Office 97 Annoyances" and "Windows 98 Annoyances".   That 
pretty much sums it up for me.

                                                     Please reply to the list;
                                                           please don't CC me.

Re: [OT] Was: ESP does not hit the nat table

[Jozsef Kadlecsik]

On Sun, 1 Aug 2004, Antony Stone wrote:

> On Sunday 01 August 2004 8:03 pm, Jason Opperisano wrote:
>
> > <OT>
> >  Where is the new-found obsession with dropping packets in the NAT table
> > coming from? </OT>
>
> Indeed.   A few people here have commented recently that they prefer dropping
> stuff in the PREROUTING nat table instead of waiting until it hits INPUT or
> FORWARD, for things like spoofed packets or invalid TCP flag combinations.

And those forget that conntrack has already seen the packets. Better use
the raw table to drop malformed/spoofed packets.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary