[Openswan Users] Aggressive mode, NAT-T, destination behind NAT

[Brian Candler]

On Wed, Apr 12, 2006 at 05:11:17PM +0200, Paul Wouters wrote:
> aggressive mode is supported, though strongly discouraged for security
> reasons.

You mean for reasons of identity protection, or something else?

When using a group pre-shared key, the fact that someone could learn that
the group is called "foo" is not always a major concern.

> If you can give us a openswan-openswan configuration that shows this problem,
> we can make a test case, and then the bug should get fixed. Assuming it is
> a bug with openswan, and not with the pix.

OK. The simplest thing for me to set up initially is using normal dynamic
source NAT, rather that static dest NAT. This gives:

         openswan B
             | 172.17.0.151
             |
             | 172.17.0.145
          firewall              ^
           (BSD)                | source NAT
             | 10.71.0.14
             |
             | 10.71.0.1
         openswan A

That is, packets from A to B appear to come from 172.17.0.145 after going
through NAT.

Configs as follows:

[/etc/ipsec.conf on A]
version 2.0     # conforms to second version of ipsec.conf specification

config setup
        plutodebug="control natt"
        nat_traversal=yes

conn test
        aggrmode=yes
        ike=3des-sha1-modp1024
        authby=secret
        pfs=no
        left=%defaultroute
        leftid=@testgroup
        leftsubnet=192.168.0.0/24
        right=172.17.0.151
        rightsubnet=192.168.1.0/24
        auto=add

#Disable Opportunistic Encryption
include /etc/ipsec.d/examples/no_oe.conf

[/etc/ipsec.conf on B]
same as A except with left=%any

[/etc/ipsec.secrets]
172.17.0.151 @testgroup : PSK "abc123"


Now starting on A:

root at OpenWrt:~# ipsec auto --verbose --up test
002 "test" #1: initiating Aggressive Mode #1, connection "test"
112 "test" #1: STATE_AGGR_I1: initiate
003 "test" #1: message ignored because it contains an unknown or unexpected payload type (ISAKMP_NEXT_NAT-D) at the outermost level
002 "test" #1: sending notification INVALID_PAYLOAD_TYPE to 172.17.0.151:500
010 "test" #1: STATE_AGGR_I1: retransmission; will wait 20s for response

And logs on B:

Jan  1 00:41:16 (none) kern.warn pluto[3640]: "test"[1] 172.17.0.145 #1: transition from state STATE_AGGR_R0 to state STATE_AGGR_R1
Jan  1 00:41:16 (none) kern.debug pluto[3640]: | sending reply packet to 172.17.0.145:54624 (from port=500)
Jan  1 00:41:16 (none) kern.debug pluto[3640]: | NAT-T: updating local port to 500
Jan  1 00:41:16 (none) kern.debug pluto[3640]: | NAT-T connection has wrong interface definition <invalid>:500 vs 172.17.0.151:500
Jan  1 00:41:16 (none) kern.debug pluto[3640]: | sending 356 bytes for STATE_AGGR_R0 through br0:500 to 172.17.0.145:54624:
Jan  1 00:41:16 (none) kern.debug pluto[3640]: | inserting event EVENT_RETRANSMIT, timeout in 10 seconds for #1
Jan  1 00:41:16 (none) kern.warn pluto[3640]: "test"[1] 172.17.0.145 #1: STATE_AGGR_R1: sent AR1, expecting AI2
Jan  1 00:41:16 (none) kern.debug pluto[3640]: | modecfg pull: noquirk policy:push not-client
Jan  1 00:41:16 (none) kern.debug pluto[3640]: | phase 1 is done, looking for phase 1 to unpend
Jan  1 00:41:16 (none) kern.debug pluto[3640]: | next event EVENT_RETRANSMIT in 10 seconds for #1
Jan  1 00:41:16 (none) kern.debug pluto[3640]: |
Jan  1 00:41:16 (none) kern.debug pluto[3640]: | *received 40 bytes from 172.17.0.145:54624 on br0 (port=500)
Jan  1 00:41:16 (none) kern.debug pluto[3640]: |  processing packet with exchange type=ISAKMP_XCHG_INFO (5)
Jan  1 00:41:16 (none) kern.debug pluto[3640]: | ICOOKIE:  e7 06 35 69  f3 30 a8 29
Jan  1 00:41:16 (none) kern.debug pluto[3640]: | RCOOKIE:  00 00 00 00  00 00 00 00
Jan  1 00:41:16 (none) kern.debug pluto[3640]: | peer:  ac 11 00 91
Jan  1 00:41:16 (none) kern.debug pluto[3640]: | state hash entry 31
Jan  1 00:41:16 (none) kern.debug pluto[3640]: | p15 state object not found
Jan  1 00:41:16 (none) kern.warn pluto[3640]: packet from 172.17.0.145:54624: ignoring informational payload, type INVALID_PAYLOAD_TYPE
Jan  1 00:41:16 (none) kern.debug pluto[3640]: | processing informational INVALID_PAYLOAD_TYPE (1)
Jan  1 00:41:16 (none) kern.warn pluto[3640]: packet from 172.17.0.145:54624: received and ignored informational message
Jan  1 00:41:16 (none) kern.debug pluto[3640]: | complete state transition with STF_IGNORE
Jan  1 00:41:16 (none) kern.debug pluto[3640]: | next event EVENT_RETRANSMIT in 10 seconds for #1

I'll start with this. Once this is working I'll set up a rig for static
destination NAT.

Regards,

Brian.