IPSec Transport Mode

IPSec Transport Mode

[Arnst, Rainer]

Hello,

I have a question regarding IPSec in Transport Mode and IPTables. I must
admitted my knowledge concerning IPSec is quite limited and so far what
I have heard about IPSec's transport and tunnel mode is not really clear
to me.

Setup is like this:

The Firewall (iptables - ipcop) has a fixed IP, the Client (MS Windows
XP) has a dynamic IP. IPSec Server is a Windows 2003 Server Box.

IPSec-Client (Internet) --> Firewall --> IPSec Server (internal)

Usually, as far as I understand, transport mode is not an option here
because of NAT being performed by the "Firewall"/Gateway.

Using MS NAT-T works fine, but we want to switch to something non-MS
soon (hopefully real soon). So it's not really an option.

With this Setup, is there anything that can be done with IPTables to
make the transport mode work w/o NAT-T?

Any comments are very appreciated.

Regards,
Rainer Arnst

Re: IPSec Transport Mode

[Antony Stone]

On Wednesday 07 July 2004 2:35 pm, Arnst, Rainer wrote:

> Hello,
>
> I have a question regarding IPSec in Transport Mode and IPTables. I must
> admitted my knowledge concerning IPSec is quite limited and so far what
> I have heard about IPSec's transport and tunnel mode is not really clear
> to me.

The difference (as far as it relates to nat) is quite simple, really:

Tunnel mode takes the original packet (TCP/IP, UDP/IP, ICMP/IP or whatever) 
and "encapsulates" it inside a completely new packet (protocol ESP = 
Encapsulated Security Payload), and that new packet gets its own completely 
new IP header (the original packet's IP header, with source & destination 
addresses, is inside the ESP payload).   The source & destination IPs on the 
ESP/IP header can be natted all you like; so long as they get to the remote 
Security Gateway, it will unpack the ESP packet, find the original IP 
headers, and send the original TCP / UDP / ICMP / whatever packet on to where 
it belongs.

Transport mode takes the original packet (TCP/IP, UDP/IP, ICMP/IP or whatever) 
and calculates a checksum over almost all of it, including the source & 
destination IP addresses, and then sends it (still with the original IP 
header, except for the fact that it's now protocol AH instead of TCP or UDP 
etc inside the IP packet), to the destination.   If you change the source or 
destination addresses along the way, then the checksum doesn't agree when it 
gets validated at the receiving end, so the secure link breaks (ie: doesn't 
work).

> Usually, as far as I understand, transport mode is not an option here
> because of NAT being performed by the "Firewall"/Gateway.

Indeed.

> Using MS NAT-T works fine, but we want to switch to something non-MS
> soon (hopefully real soon). So it's not really an option.
>
> With this Setup, is there anything that can be done with IPTables to
> make the transport mode work w/o NAT-T?

I can think of two ways:

1. Put a genuine public IP address on the destination Security Gateway 
machine, routed through the firewall without nat.

2. Perform nat twice so that the packet as received by the SG is exactly as it 
was sent, even though it may have been natted (and then un-natted) along the 
way.   This almost certainly involves putting a public IP on the remote SG, 
and having two firewalls to perform the two nat operations.

Regards,

Antony.

-- 
"640 kilobytes (of RAM) should be enough for anybody."

 - Bill Gates

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

Re: IPSec Transport Mode

[Arnst, Rainer]

Hello,

thank you Antony for your quick and very helpful answer!!

On Mi, 2004-07-07 at 15:53, Antony Stone wrote:
> > With this Setup, is there anything that can be done with IPTables to
> > make the transport mode work w/o NAT-T?
> 
> I can think of two ways:
> 1. Put a genuine public IP address on the destination Security Gateway 
> machine, routed through the firewall without nat.

This sounds really good. How do I tell iptables not to perform NAT for
IPSec?

Currently the firewall is a Test-Setup with IPCop. Since the
IpCop-Interface does not support ESP I added these iptables rules to the
zillions of rules put in place by ipcop to make it work, probably a bit
to open anyway :-) :

iptables -A INPUT -p 50 -j ACCEPT
iptables -A OUTPUT -p 50 -j ACCEPT
iptables -A FORWARD -p 50 -j ACCEPT

How would I modify these to pass on the packets without NAT?

Thanks a lot,
Rainer Arnst

RE: IPSec Transport Mode

[listuser]

HiHo!

NAT-T (or nat-traversal) is the also a solution as you stated yourself.
It is also available for several other IPsec solutions.
Yet for FreeSwan you need at least a patch (nat-traversal) or use
superfreeswan (www.freeswan.ca) . I don't know about
other implementations, esp the new derived ones.

Nat-traversal encapsulates the complete packets into yet another UDP
packet destenied for port 4500. This can be natted as usual. The
otherside simply has to pick the ipsec packet from the udp packet.
So NAT-T must be used on both sides, yet it has the advantage that 
it is more transparent.

ciao
  markus
 

Re: IPSec Transport Mode

[Antony Stone]

On Wednesday 07 July 2004 3:21 pm, Arnst, Rainer wrote:

> Hello,
>
> thank you Antony for your quick and very helpful answer!!
>
> On Mi, 2004-07-07 at 15:53, Antony Stone wrote:
> > > With this Setup, is there anything that can be done with IPTables to
> > > make the transport mode work w/o NAT-T?
> >
> > I can think of two ways:
> > 1. Put a genuine public IP address on the destination Security Gateway
> > machine, routed through the firewall without nat.
>
> This sounds really good. How do I tell iptables not to perform NAT for
> IPSec?
>
> Currently the firewall is a Test-Setup with IPCop. Since the
> IpCop-Interface does not support ESP I added these iptables rules to the
> zillions of rules put in place by ipcop to make it work, probably a bit
> to open anyway :-) :
>
> iptables -A INPUT -p 50 -j ACCEPT
> iptables -A OUTPUT -p 50 -j ACCEPT
> iptables -A FORWARD -p 50 -j ACCEPT
>
> How would I modify these to pass on the packets without NAT?

My first observation on seeing this is: why are you talking about ESP all of a 
sudden?

ESP is for tunnel mode, and works fine through NAT.

Transport mode uses AH (protocol 51), and that's the one which breaks through 
NAT.

Anyway, you don't need to FORWARD the IPsec packets - they only come into and 
out of the security gateway machine - it's the unencrypted packets which get 
FORWARDed.

And, to answer your question about how to avoid NATting certain types of 
packets, the answer is to put an ACCEPT rule in your PREROUTING or 
POSTROUTING chain, before the SNAT or DNAT rule which would otherwise nat 
them.

For example:

iptables -A PREROUTING -t nat -p 50 -j ACCEPT
iptables -A PREROUTING -t nat -d a.b.c.d -j DNAT --to w.x.y.z

These rules will DNAT all packets originally addressed to a.b.c.d and send 
them to w.x.y.z instead, *unless* they are protocol 50, in which case they 
won't get NATted.

Hope that helps,

Antony.

-- 
The first fifty percent of an engineering project takes ninety percent of the 
time, and the remaining fifty percent takes another ninety percent of the 
time.

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

Re: IPSec Transport Mode

[Sven Schuster]

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


Hi Antony,

On Wed, Jul 07, 2004 at 09:54:52PM +0100, Antony Stone told us:
> 
> ESP is for tunnel mode, and works fine through NAT.
> 
> Transport mode uses AH (protocol 51), and that's the one which breaks through 
> NAT.

Isn't using AH or ESP independent from tunnel/transport mode?? AH
mode is just authentication, ESP is authentication + encryption. You
can use AH with tunnel mode and ESP with transport mode like you
wish I think.


Sven

-- 
Linux zion 2.6.7 #1 Thu Jun 17 10:44:26 CEST 2004 i686 athlon i386 GNU/Linux
 23:08:58  up 7 days,  6:52,  3 users,  load average: 0.06, 0.05, 0.00

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: IPSec Transport Mode

[Antony Stone]

On Wednesday 07 July 2004 10:11 pm, Sven Schuster wrote:

> Hi Antony,
>
> On Wed, Jul 07, 2004 at 09:54:52PM +0100, Antony Stone told us:
> > ESP is for tunnel mode, and works fine through NAT.
> >
> > Transport mode uses AH (protocol 51), and that's the one which breaks
> > through NAT.
>
> Isn't using AH or ESP independent from tunnel/transport mode?? AH
> mode is just authentication, ESP is authentication + encryption. You
> can use AH with tunnel mode and ESP with transport mode like you
> wish I think.

Hm, not sure about this - I've never wanted a VPN without encryption, so I've 
not experimented with AH tunnels.

Also, if you can do transport mode with ESP, then it should work through NAT 
without problems, because the original packet gets encapsulated (as per my 
previous explanation).

Regards,

Antony.

-- 
"There is no reason for any individual to have a computer in their home."

 - Ken Olsen, President of Digital Equipment Corporation (DEC, later consumed 
by Compaq, later merged with HP)

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

Re: IPSec Transport Mode

[Cedric Blancher]

Le mer 07/07/2004 à 23:42, Antony Stone a écrit :
> Also, if you can do transport mode with ESP, then it should work through NAT 
> without problems, because the original packet gets encapsulated (as per my 
> previous explanation).

Nope.
Only ESP tunnel mode can go through NAT. The main difference between
transport mode and tunnel is that tunnel encapsulate the whole IP packet
when transport mode only encapsulate IP payload only (for IP destination
and IPSEC destination are the same).

If you try to do NAT, then you will modify IP header, and then TCP
checksum, which is ciphered will get false for it also include IP
adresses in its calculation.

-- 
http://www.netexit.com/~sid/
PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE
>> Hi! I'm your friendly neighbourhood signature virus.
>> Copy me to your signature file and help me spread!

Re: IPSec Transport Mode

[Rainer Arnst]

On Wed, 2004-07-07 at 22:54, Antony Stone wrote:
> For example:
> 
> iptables -A PREROUTING -t nat -p 50 -j ACCEPT
> iptables -A PREROUTING -t nat -d a.b.c.d -j DNAT --to w.x.y.z
> 
> These rules will DNAT all packets originally addressed to a.b.c.d and send 
> them to w.x.y.z instead, *unless* they are protocol 50, in which case they 
> won't get NATted.
> 
> Hope that helps,

Perfect, I'll try that immediately! Thanks again to everybody who
participated.

Greetings,
Rainer

Re: IPSec Transport Mode

[Rainer Arnst]

Hi everybody...

On Wed, 2004-07-07 at 22:54, Antony Stone wrote:
> And, to answer your question about how to avoid NATting certain types of 
> packets, the answer is to put an ACCEPT rule in your PREROUTING or 
> POSTROUTING chain, before the SNAT or DNAT rule which would otherwise nat 
> them.
> 
> For example:
> 
> iptables -A PREROUTING -t nat -p 50 -j ACCEPT
> iptables -A PREROUTING -t nat -d a.b.c.d -j DNAT --to w.x.y.z
> 
> These rules will DNAT all packets originally addressed to a.b.c.d and send 
> them to w.x.y.z instead, *unless* they are protocol 50, in which case they 
> won't get NATted.

I tried to work with that, but failed to produce the desired results,
which were to enable IPSec transport mode packets to pass through the
firewall not being NATed. I put these rules at the beginning of the
PREROUTING Chain:

iptables -A PREROUTING -t nat -p 50 -j ACCEPT
iptables -A PREROUTING -t nat -p 51 -j ACCEPT

Got anyone any ideas? What should the ips and routing tables look like?

Thanks and sorry for asking a possibly silly question... I am quite new
to this matter!

Regards,
Rainer

Re: IPSec Transport Mode

[Cedric Blancher]

Le ven 09/07/2004 à 17:38, Rainer Arnst a écrit :
> I tried to work with that, but failed to produce the desired results,
> which were to enable IPSec transport mode packets to pass through the
> firewall not being NATed.
[...]
> Got anyone any ideas?

Yes, I got one I previously explained. IPSEC transport mode can't cope
with NAT if you do TCP. ESP transport port only encapsulate IP packet
payload (layer 4) as opposed to ESP tunnel which encapsulate full IP
packet.

When you do NAT, you alter IP source and/or destination. But TCP
checksum includes IP addresses, which means you have to recompute it on
the fly when NATing. Anf for it is ciphered, you can't.


-- 
http://www.netexit.com/~sid/
PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE
>> Hi! I'm your friendly neighbourhood signature virus.
>> Copy me to your signature file and help me spread!

Re: IPSec Transport Mode

[Rainer Arnst]

On Fri, 2004-07-09 at 18:13, Cedric Blancher wrote:
> Le ven 09/07/2004 à 17:38, Rainer Arnst a écrit :
> > I tried to work with that, but failed to produce the desired results,
> > which were to enable IPSec transport mode packets to pass through the
> > firewall not being NATed.
> [...]
> > Got anyone any ideas?
> 
> Yes, I got one I previously explained. IPSEC transport mode can't cope
> with NAT if you do TCP. ESP transport port only encapsulate IP packet
> payload (layer 4) as opposed to ESP tunnel which encapsulate full IP
> packet.

I know, that is why I wanted to avoid NAT for ESP/AH, passing packets
through without rewriting their destination, following this suggestion
from Antony@Soft-Solutions.co.uk:

> 1. Put a genuine public IP address on the destination Security Gateway
> machine, routed through the firewall without nat.

> When you do NAT, you alter IP source and/or destination. But TCP
> checksum includes IP addresses, which means you have to recompute it on
> the fly when NATing. Anf for it is ciphered, you can't.

Unfortuneately I have to find a way to make the transport mode work; we
were using NAT-T, which worked fine, but now I am looking for another
solution which does not require the VPN Gateway to support NAT-T.

Greetings,
Rainer

Re: IPSec Transport Mode

[ming fu]

Rainer Arnst wrote:

>>When you do NAT, you alter IP source and/or destination. But TCP
>>checksum includes IP addresses, which means you have to recompute it on
>>the fly when NATing. Anf for it is ciphered, you can't.
>>    
>>
>
>Unfortuneately I have to find a way to make the transport mode work; we
>were using NAT-T, which worked fine, but now I am looking for another
>solution which does not require the VPN Gateway to support NAT-T.
>  
>
If you are using NAT-T for outbound IPSEC connections, open udp port 500 
and 4500 and source nat them. Just do not load any "smart VPN proxy" 
that would alter other parts of the UDP, the simplest udp NAT will do 
the trick.

>Greetings,
>Rainer
>
>  
>