IPSec through my firewall

IPSec through my firewall

[Ola Nilsson]

Hello,

I've got problems with getting IPSec (using NAT-T) traffic through my
Linux 2.6.10 based firewall. I've now changed my iptables script to
something rather simple:

iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Which is far to open, but I used it to try to find the problem. What I
see with Ethereal is that the connection seems to have two
phases. Both phases uses UDP on port 4500. In the first phase ISAKMP
is used, then ESP.

192.168.3.249   is the IP of the machine on my LAN that wants to do IPSec.
1.2.3.4         is the IP of the other end of the IPSec tunnel
5.6.7.8         is the IP of my firewalls interface on the internet

This is what I see:

No.     Time        Source          Destination     Protocol Info
      3 0.001148    192.168.3.249   1.2.3.4         ISAKMP   Aggressive
      4 0.001165    5.6.7.8         1.2.3.4         ISAKMP   Aggressive
      5 9.999541    1.2.3.4         5.6.7.8         ISAKMP   Aggressive
      6 9.999586    1.2.3.4         192.168.3.249   ISAKMP   Aggressive

    460 77.461355   192.168.3.249   1.2.3.4         ESP      ESP (SPI=0x384a545c)
    461 77.461383   192.168.3.249   1.2.3.4         ESP      ESP (SPI=0x384a545c)
    462 78.961453   192.168.3.249   1.2.3.4         ESP      ESP (SPI=0x384a545c)

During the ISAKMP phase, my firewall NATs like it shall, and the
client reports the tunnel as working. But once the real ESP traffic
starts to flow, it doesn't get NATed as I would like it to.

I've googled quite a lot, and also tried using firehol to set up the
iptables (and gotten some help on the firehol forum), but I'm still
unsuccessfull. What should I do to debug this? Anyone have a set of
rules that allows ISAKMP/ESP on UDP port 4500?

Regards,
-- 
/Ola Nilsson

Re: IPSec through my firewall

[Michael Gale]

Hello,

	You can not NAT ESP (protocol 50) traffic. Some IPSEC clients and 
servers support NATing but I believe this requires special 
implementation on the client and server end.

If you want to NAT a VPN tunnel I suggest you try a SSL base VPN. 
OpenVPN works well, you could also try TCP or UDP encapsulation to help 
get around the NAT issue.

Michael.


Ola Nilsson wrote:
> Hello,
> 
> I've got problems with getting IPSec (using NAT-T) traffic through my
> Linux 2.6.10 based firewall. I've now changed my iptables script to
> something rather simple:
> 
> iptables -P INPUT ACCEPT
> iptables -P OUTPUT ACCEPT
> iptables -P FORWARD ACCEPT
> iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
> 
> Which is far to open, but I used it to try to find the problem. What I
> see with Ethereal is that the connection seems to have two
> phases. Both phases uses UDP on port 4500. In the first phase ISAKMP
> is used, then ESP.
> 
> 192.168.3.249   is the IP of the machine on my LAN that wants to do IPSec.
> 1.2.3.4         is the IP of the other end of the IPSec tunnel
> 5.6.7.8         is the IP of my firewalls interface on the internet
> 
> This is what I see:
> 
> No.     Time        Source          Destination     Protocol Info
>       3 0.001148    192.168.3.249   1.2.3.4         ISAKMP   Aggressive
>       4 0.001165    5.6.7.8         1.2.3.4         ISAKMP   Aggressive
>       5 9.999541    1.2.3.4         5.6.7.8         ISAKMP   Aggressive
>       6 9.999586    1.2.3.4         192.168.3.249   ISAKMP   Aggressive
> 
>     460 77.461355   192.168.3.249   1.2.3.4         ESP      ESP (SPI=0x384a545c)
>     461 77.461383   192.168.3.249   1.2.3.4         ESP      ESP (SPI=0x384a545c)
>     462 78.961453   192.168.3.249   1.2.3.4         ESP      ESP (SPI=0x384a545c)
> 
> During the ISAKMP phase, my firewall NATs like it shall, and the
> client reports the tunnel as working. But once the real ESP traffic
> starts to flow, it doesn't get NATed as I would like it to.
> 
> I've googled quite a lot, and also tried using firehol to set up the
> iptables (and gotten some help on the firehol forum), but I'm still
> unsuccessfull. What should I do to debug this? Anyone have a set of
> rules that allows ISAKMP/ESP on UDP port 4500?
> 
> Regards,

-- 
Michael Gale
Lan Administrator
Utilitran Corp.

Hey, let me file that under important .... > /dev/null
...
"Hey did you read my e-mail"
"Let my check"
^From:.* > /dev/null
"Nope, I missed it, send it again"

Re: IPSec through my firewall

[Jason Opperisano]

On Tue, Feb 15, 2005 at 11:25:58AM +0100, Ola Nilsson wrote:
> Hello,
> 
> I've got problems with getting IPSec (using NAT-T) traffic through my
> Linux 2.6.10 based firewall. I've now changed my iptables script to
> something rather simple:
> 
> iptables -P INPUT ACCEPT
> iptables -P OUTPUT ACCEPT
> iptables -P FORWARD ACCEPT
> iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
> 
> Which is far to open, but I used it to try to find the problem. What I
> see with Ethereal is that the connection seems to have two
> phases. Both phases uses UDP on port 4500. In the first phase ISAKMP
> is used, then ESP.

um--i'll admit that i'm being lazy and not pulling up the RFC (or
draft), but i'm pretty sure that phase 1 must still use UDP 500, as
NAT-T must be negotiated between the two peers.  after that--phase 2 and
the bulk encryption traffic can use UDP port 4500.  again--i could be
totally wrong about this, but i don't see how it could work otherwise.

> 192.168.3.249   is the IP of the machine on my LAN that wants to do IPSec.
> 1.2.3.4         is the IP of the other end of the IPSec tunnel
> 5.6.7.8         is the IP of my firewalls interface on the internet
> 
> This is what I see:
> 
> No.     Time        Source          Destination     Protocol Info
>       3 0.001148    192.168.3.249   1.2.3.4         ISAKMP   Aggressive
>       4 0.001165    5.6.7.8         1.2.3.4         ISAKMP   Aggressive
>       5 9.999541    1.2.3.4         5.6.7.8         ISAKMP   Aggressive
>       6 9.999586    1.2.3.4         192.168.3.249   ISAKMP   Aggressive
> 
>     460 77.461355   192.168.3.249   1.2.3.4         ESP      ESP (SPI=0x384a545c)
>     461 77.461383   192.168.3.249   1.2.3.4         ESP      ESP (SPI=0x384a545c)
>     462 78.961453   192.168.3.249   1.2.3.4         ESP      ESP (SPI=0x384a545c)

"this is what you see" where?  what is this the output of?  where is
this output being generated?

also, realize that the output (wherever it's coming from) is saying that
you're using ISAKMP (which would imply standard UDP Port 500), and ESP
(IP Protocol 50)--i don't see any indication of NAT-T or UDP Port 4500
anywhere in that output.

as an aside--the use of IKE Aggressive Mode has been frowned upon for
quite some time--consider disabling it if you admin both sides of this
tunnel...

> During the ISAKMP phase, my firewall NATs like it shall, and the
> client reports the tunnel as working. But once the real ESP traffic
> starts to flow, it doesn't get NATed as I would like it to.

well--if you're transmitting "real ESP" traffic; i.e., IP Protocol
50--then you are not using NAT-T and that would explain your problem.

> I've googled quite a lot, and also tried using firehol to set up the
> iptables (and gotten some help on the firehol forum), but I'm still
> unsuccessfull. What should I do to debug this? Anyone have a set of
> rules that allows ISAKMP/ESP on UDP port 4500?

um--it shouldn't really be all that complicated.  since you have no
firewall rules at the moment--i would propose that at the current time,
you have an IPSec problem, not a firewall problem (though your IPSec
problem may be NAT-related).

i don't think we have enough info to help you at this time.

-j

--
"Me fail English? That's unpossible."
        --The Simpsons

Re: IPSec through my firewall

[Ola Nilsson]

Hie,

I would've tried something different if I had the possibility to
choose. This is a solution chosen by the company I work for.

Are you sure about that IPSec can't be NATed? NAT-T is kind of meant to
handle just that. Also, my colleagues have no trouble through
e.g. D-Link routers. The ISAKMP part NATs just fine...

Regards,
/Ola

Michael Gale <michael.gale@utilitran.com> writes:

> Hello,
>
> 	You can not NAT ESP (protocol 50) traffic. Some IPSEC clients
> and servers support NATing but I believe this requires special
> implementation on the client and server end.
>
> If you want to NAT a VPN tunnel I suggest you try a SSL base
> VPN. OpenVPN works well, you could also try TCP or UDP encapsulation
> to help get around the NAT issue.
>
> Michael.

-- 
/Ola Nilsson

Re: IPSec through my firewall

[Michael Gale]

Hello,

	This all depends on your implementation, I believe the standard 
protocol 50 (ESP) traffic still does not support NAT. But there are a 
lot of vendors out there that have NAT "aware" VPN devices.

Some devices use UDP encapsulation, others allow a more relaxed version 
of the IPSEC protocol to handle the NAT.

Some only support NAT during one point in the connection, so both the 
client and server can't use NAT, only one or the other.

 From the RFC's:

--snip--
Negotiation of the NAT-Traversal Encapsulation

    The negotiation of the NAT-Traversal happens by adding two new
    encapsulation modes.  These encapsulation modes are

    UDP-Encapsulated-Tunnel         3
    UDP-Encapsulated-Transport      4

    It is not normally useful to propose both normal tunnel or transport
    mode and UDP-Encapsulated modes.  UDP encapsulation is required to
    fix the inability to handle non-UDP/TCP traffic by NATs (see
    [RFC3715], section 2.2, case i).

    If there is a NAT box between hosts, normal tunnel or transport
    encapsulations may not work.  In this case, UDP-Encapsulation SHOULD
    be used.
--snip--

I would allow all traffic between the client and server on UDP ports 500 
and 4500.

iptables -I -i EXT_FACE -o VPN_FACE -d X.X.X.X -p udp --dport 500 -j ACCEPT
iptables -I -i EXT_FACE -o VPN_FACE -d X.X.X.X -p udp --dport 4500 -j ACCEPT

Michael.

Ola Nilsson wrote:
> Hie,
> 
> I would've tried something different if I had the possibility to
> choose. This is a solution chosen by the company I work for.
> 
> Are you sure about that IPSec can't be NATed? NAT-T is kind of meant to
> handle just that. Also, my colleagues have no trouble through
> e.g. D-Link routers. The ISAKMP part NATs just fine...
> 
> Regards,
> /Ola
> 
> Michael Gale <michael.gale@utilitran.com> writes:
> 
> 
>>Hello,
>>
>>	You can not NAT ESP (protocol 50) traffic. Some IPSEC clients
>>and servers support NATing but I believe this requires special
>>implementation on the client and server end.
>>
>>If you want to NAT a VPN tunnel I suggest you try a SSL base
>>VPN. OpenVPN works well, you could also try TCP or UDP encapsulation
>>to help get around the NAT issue.
>>
>>Michael.
> 
> 

-- 
Michael Gale
Lan Administrator
Utilitran Corp.

Hey, let me file that under important .... > /dev/null
...
"Hey did you read my e-mail"
"Let my check"
^From:.* > /dev/null
"Nope, I missed it, send it again"

Re: IPSec through my firewall

[Ola Nilsson]

Jason Opperisano <opie@817west.com> writes:

> On Tue, Feb 15, 2005 at 11:25:58AM +0100, Ola Nilsson wrote:
>> Which is far to open, but I used it to try to find the problem. What I
>> see with Ethereal is that the connection seems to have two
>> phases. Both phases uses UDP on port 4500. In the first phase ISAKMP
>> is used, then ESP.

...snip

> "this is what you see" where?  what is this the output of?  where is
> this output being generated?

First, to all that replied, thanks for your help!

I will try to read up on the RFCs. Might be that I was fooled to
believe that NAT-T was used due to some log entries in the
clients. Now I understand that I should be looking at the ESP traffic,
since that should not necessarily NAT OK. Is this why the kernel helps
me, and refuses to NAT the ESP packages?

Regarding where the output was from, it was what I see listening on
both interfaces of the firewall with Ethereal. Even though my
understanding also was that other ports than 4500 should have been
used, all traffic is on port 4500 (nothing on 500).

Regards, 
-- 
/Ola Nilsson

Re: IPSec through my firewall

[rowdy]

On Tuesday 15 February 2005 09:15, Ola Nilsson wrote:
> I've got problems with getting IPSec (using NAT-T) traffic through my
> Linux 2.6.10 based firewall. I've now changed my iptables script to
> something rather simple:
>
> iptables -P INPUT ACCEPT
> iptables -P OUTPUT ACCEPT
> iptables -P FORWARD ACCEPT
> iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

I've been struggling with this as well.  Take a look at 
http://www.freeswan.org/freeswan_snaps/CURRENT-SNAP/doc/firewall.html .

I used this query to find this link and a number of others that could be 
helpful: "esp ipsec firewall rule"

I added rules like the following (but to user chains that I then added to the 
input, output and forward chains) to solve my hassles (clipped from the 
freeswan link above):
 
# allow IPsec
#
# IKE negotiations
iptables -I INPUT  -p udp --sport 500 --dport 500 -j ACCEPT
iptables -I OUTPUT -p udp --sport 500 --dport 500 -j ACCEPT
# ESP encryption and authentication
iptables -I INPUT  -p 50 -j ACCEPT
iptables -I OUTPUT -p 50 -j ACCEPT

Good luck.

Re: IPSec through my firewall

[Georgi Alexandrov]

rowdy wrote:

>On Tuesday 15 February 2005 09:15, Ola Nilsson wrote:
>  
>
>>I've got problems with getting IPSec (using NAT-T) traffic through my
>>Linux 2.6.10 based firewall. I've now changed my iptables script to
>>something rather simple:
>>
>>iptables -P INPUT ACCEPT
>>iptables -P OUTPUT ACCEPT
>>iptables -P FORWARD ACCEPT
>>iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
>>    
>>
>
>I've been struggling with this as well.  Take a look at 
>http://www.freeswan.org/freeswan_snaps/CURRENT-SNAP/doc/firewall.html .
>
>I used this query to find this link and a number of others that could be 
>helpful: "esp ipsec firewall rule"
>
>I added rules like the following (but to user chains that I then added to the 
>input, output and forward chains) to solve my hassles (clipped from the 
>freeswan link above):
> 
># allow IPsec
>#
># IKE negotiations
>iptables -I INPUT  -p udp --sport 500 --dport 500 -j ACCEPT
>iptables -I OUTPUT -p udp --sport 500 --dport 500 -j ACCEPT
># ESP encryption and authentication
>iptables -I INPUT  -p 50 -j ACCEPT
>iptables -I OUTPUT -p 50 -j ACCEPT
>
>Good luck.
>
>
>  
>
hello,

that's more than pointless as he has INPUT, OUTPUT and FORWARD policies 
set to ACCEPT and no other rules.


regards,
Georgi Alexandrov

Re: IPSec through my firewall

[Ola Nilsson]

Georgi Alexandrov <tehlists@hotpop.com> writes:

> rowdy wrote:
>> I added rules like the following (but to user chains that I then
>> added to the input, output and forward chains) to solve my hassles
>> (clipped from the freeswan link above):
>> # allow IPsec
>>#
>># IKE negotiations
>>iptables -I INPUT  -p udp --sport 500 --dport 500 -j ACCEPT
>>iptables -I OUTPUT -p udp --sport 500 --dport 500 -j ACCEPT
>># ESP encryption and authentication
>>iptables -I INPUT  -p 50 -j ACCEPT
>>iptables -I OUTPUT -p 50 -j ACCEPT
>>
..snip
> that's more than pointless as he has INPUT, OUTPUT and FORWARD
> policies set to ACCEPT and no other rules.

Even so, I'm thankfull for any suggestions. 

So, going back to my initial question; How can I go about finding out
where my packets are droped? Since it's most likelly not because of
any netfilter rule entry, who else can decide that a packet can not be
NATed?

-- 
/Ola Nilsson

Re: IPSec through my firewall

[Samuel Jean]

On Wed, February 16, 2005 7:46 am, Ola Nilsson said:
> So, going back to my initial question; How can I go about finding out
where my packets are droped? Since it's most likelly not because of any
netfilter rule entry, who else can decide that a packet can not be
NATed?

Sorry, I haven't followed the thread at all.

To answer this question, some malformed, suspicious packets can be dropped
by the netfilter code itself, and even the networking code.

I don't pretend it's your case but anyway, you can patch your kernel with
the dropped-table patch (available from patch-o-matic).

This will let you log dropped packets.

Also, if you're worried about where in your ruleset the packet gets
dropped, use nf-log, raw table, TRACE patches to get a complete packets
traversal logging.

Hope am not way off the subject.

>
> --
> /Ola Nilsson
>
>
>

Cheers,
Samuel

Re: IPSec through my firewall

[Jean Caron]

Ola Nilsson writes: 

> Georgi Alexandrov <tehlists@hotpop.com> writes: 
> 
>> rowdy wrote:
>>> I added rules like the following (but to user chains that I then
>>> added to the input, output and forward chains) to solve my hassles
>>> (clipped from the freeswan link above):
>>> # allow IPsec
>>>#
>>># IKE negotiations
>>>iptables -I INPUT  -p udp --sport 500 --dport 500 -j ACCEPT
>>>iptables -I OUTPUT -p udp --sport 500 --dport 500 -j ACCEPT
>>># ESP encryption and authentication
>>>iptables -I INPUT  -p 50 -j ACCEPT
>>>iptables -I OUTPUT -p 50 -j ACCEPT 
>>>
> ..snip
>> that's more than pointless as he has INPUT, OUTPUT and FORWARD
>> policies set to ACCEPT and no other rules.
> 
> Even so, I'm thankfull for any suggestions.  
> 
> So, going back to my initial question; How can I go about finding out
> where my packets are droped? Since it's most likelly not because of
> any netfilter rule entry, who else can decide that a packet can not be
> NATed? 
> 
> -- 
> /Ola Nilsson 
> 
> 
Ola, 

Your problem is directly related to NAT. You can not use NAT. ESP will not 
establish any security association if the source or destination address have 
been modified, which is exactly what NAT does to your packets. In order for 
this to work, you need to encapsulate your ESP (IPsec) traffic within either 
UDP or TCP. NAT-Traversal does this. Different vendors implement this using 
different ports.protocol, but essentially they are encapsulating the orignal 
packets, hiding the info from NAT. 

The iptable rules above are exactly what you'd need if the tunnel was 
terminating ON the firewall. But to terminate it PAST the firewall, unless 
you use public addresses everywhere (no NAT), you will need to encapsulate, 
and define approriate (additional) rules on your firewall fot the NAT-T port 
used. 

Hope this helps,
Jean 

Re: IPSec through my firewall

[Ola Nilsson]

"Jean Caron" <caronj@norac.net> writes:
> Ola, Your problem is directly related to NAT. You can not use NAT. ESP
> will not establish any security association if the source or
> destination address have been modified, which is exactly what NAT does
> to your packets. In order for this to work, you need to encapsulate
> your ESP (IPsec) traffic within either UDP or TCP. NAT-Traversal does
> this. Different vendors implement this using different ports.protocol,
> but essentially they are encapsulating the orignal packets, hiding the
> info from NAT. The iptable rules above are exactly what you'd need if
> the tunnel was terminating ON the firewall. But to terminate it PAST
> the firewall, unless you use public addresses everywhere (no NAT), you
> will need to encapsulate, and define approriate (additional) rules on
> your firewall fot the NAT-T port used. Hope this helps,
> Jean

Right. I went back to Ethereal to have another look. It seems to
report the inner most protocol it can decode (in the view I posted
initially). Looking at the packet in detail gives this:

Frame 275 (160 bytes on wire, 160 bytes captured)
Linux cooked capture
Internet Protocol, Src Addr: 102.168.3.249 (192.168.3.249). Dst Addr: 1.2.3.4 (1.2.3.4)
user Datagram Protocol, Src Port: 4500 (4500), Dst Port: 4500 (4500)
UDP Encapsulation of IPsec Packets
Encapsulating Security Payload

So, you're right it is encapsulated in some form. Also, colleagues
using e.g. D-Link routers have no problems connecting. So the traffic
should NAT OK. I will now try the patch-o-matic dropped-table to try
to understand we the packets get dropped instead of NATed (as
suggested by Samuel Jean).

-- 
/Ola Nilsson