How to apply NAT before IPSec on outgoing packets

[Daniel Zebralla \(A.P.E. IT-Security - Hard- & Software Development\)]

Hi,

we have a network setup where we have a NAT-router (running NetBSD 5.0-release) communicating with a VPN gateway through IPSec-tunnel mode. The NAT-Router should forward all packets from the internal network to the remote site.
We are currently experiencing problems with NAT in combination with IPsec.

Our setup:

Internal LAN <====> router <====> IPSec over public network <=> VPN-GW <=> Corporate LAN

So far, the IPSec-tunnel comes up (using raccoon and tunnel mode), but the problem is that our router also needs to do NAT on outgoing packets so that we can allow the same IP addresses for internal LANs on several sites. Currently, we use the external network interface for NAT.

We see problems when sending a packet from the internal LAN to the corporate LAN: After NAT, the IPSec encryption needs to be applied on the source IP addresses. The IPsec configuration currently is for the NATed network on the local side, and everything (0.0.0.0) on the remote side.

Using tcpdump and code inspection, we found out that IPSec encryption is applied before NAT, so in our case, no IPsec encryption is done at all (as we only encrypt what comes from the NATed network), and the packets are sent unencrypted after NAT was applied on them.

What we would need is to first get our source IP address go through NAT, and then have IPsec processing applied.

We found an older posting http://mail-index.netbsd.org/tech-net/2009/06/12/msg001385.html regarding the same problem in the opposite direction. Therefore we expect that we also need to patch the kernel sources in order to make our system apply NAT first and IPSec after that on outgoing packets.

If anyone has a similar configuration running or can advise us where to look inside the kernel sources to get this done, this would be much appreciated.

We're glad to provide more details if needed.
Please CC: me on replies as I'm not subscribed to this list (yet).

Thanks in advance!
- Daniel

A.P.E. GmbH
Hard- & Software Development
Daniel Zebralla
Galgenbergstraße 2a - Posthof
93053 Regensburg - Germany
Telefon [phone]
Telefax [phone]
***@ape-net.com
http://www.ape-net.com

_______________________________________

A.P.E. GmbH  IT-Security
Sitz der Gesellschaft: Regensburg
Handelsregister: HRB 5953, Regensburg
Geschäftsführer: Dr. Dieter Steiner



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Daniel Zebralla \(A.P.E. IT-Security - Hard- & Software Development\)]

Here's an update since my last mail: We've applied a patch (attached below) to the ip_output.c file in the kernel.
We copied the part for running the PFIL_HOOKS above the IPSEC- and FAST_IPSEC-processing so that NAT shall be applied before IPSec.

Unfortunately the results were somehow confusing. Here's what happens:

Test 1 - Ping from client inside internal LAN to client inside corporate LAN.
We tcpdump'ed on the external interface of our NetBSD-router on the client side.
Effects we see:
- The IPSec-tunnel is set up correctly (tunnel mode) thanks to racoon
- The NetBSD-router sends encrypted ICMP (destination unreachable) messages into the IPSec tunnel with his internal IP NAT'ed and the host
residing in the internal LAN as destination (no NAT)
- tcpdump on the internal interface shows that ping-packets are sent to our router but nothing is sent back

Test 2 - Ping from client inside internal LAN to internal interface of our NetBSD-router (client side).
In the router's internal interface, we see:
- (tcpdump on the internal interface shows that ping-packets are sent to our router with normal speed but nothing is sent back)
What we see on our routers' external interface:
- The IPSec-tunnel is set up correctly, again in tunnel mode
- The NetBSD-router sends this ping encrypted and NAT'ed into the IPSec tunnel, and the vpn-gw sends it (also encrypted) back to our router,
who's sending the packet back to the vpn-gw and so on (routing loop)
- this results in a flooding of the tunnel until the TTL on the encapsulated ping request is expired and the next ping coming from the
client is sent into the tunnel starting all this flooding again

One other observation is that we can decrypt the packets from the corporate IPsec VPN router to our NetBSD router (using Wireshark),
but that we cannot decrypt the packets going out of our NetBSD router, with the data given by "setkey -D".

Does anyone have a good hint here on how to proceed?

On a related note: we've seen that OpenBSD comes with an enc(4) network interface dedicated to IPsec traffic, where filter/NAT rules can be applied before encrypting and after decrypting. The driver's source is rather short, but I guess there are deep interactions with OpenBSD's IPsec implementation. Has anyone looked into porting/implementing this framework to/on NetBSD?`


1 Index: ip_output.c
2 ===================================================================
3 RCS file: /cvsroot/src/sys/netinet/ip_output.c,v
4 retrieving revision 1.200.4.1
5 diff -u -r1.200.4.1 ip_output.c
6 --- ip_output.c 9 Jul 2009 19:38:27 -0000 1.200.4.1
7 +++ ip_output.c 6 Nov 2009 15:39:02 -0000
8 @@ -505,6 +505,24 @@
9 /* Remember the current ip_len */
10 ip_len = ntohs(ip->ip_len);
11
12 +#if defined(IPSEC) || defined(FAST_IPSEC)
13 +#ifdef PFIL_HOOKS
14 + /*
15 + * Run through list of hooks for output packets before they are processed by
16 + * IPSEC / FAST_IPSEC. - DZ
17 + */
18 + if ((error = pfil_run_hooks(&inet_pfil_hook, &m, ifp, PFIL_OUT)) != 0)
19 + goto done;
20 + if (m == NULL)
21 + goto done;
22 +
23 + ip = mtod(m, struct ip *);
24 + hlen = ip->ip_hl << 2;
25 + ip_len = ntohs(ip->ip_len);
26 +#endif /* PFIL_HOOKS */
27 +#endif /* defined(IPSEC) || defined(FAST_IPSEC) */
28 +
29 +
30 #ifdef IPSEC
31 /* get SP for this packet */
32 if (so == NULL)


Kind regards,
- Daniel


A.P.E. GmbH
Hard- & Software Development
Daniel Zebralla
Galgenbergstraße 2a - Posthof
93053 Regensburg - Germany
Telefon [phone]
Telefax [phone]
***@ape-net.com
http://www.ape-net.com

_______________________________________

A.P.E. GmbH IT-Security
Sitz der Gesellschaft: Regensburg
Handelsregister: HRB 5953, Regensburg
Geschäftsführer: Dr. Dieter Steiner


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de