strongSwan

It would help if you would

1) set iptables input/output policy on the server to drop and add the udp port 500/4500 rules as in our example NAT scenario
http://www.strongswan.org/uml/testresults43/ikev2/nat-one-rw/sun.iptables

2) post the output of the command ip xfrm policy and ip xfrm state on the server

3) post the output of ipsec statusall on the server

and all this after you tried to transmit a couple of packets via L2TP

Regards

Andreas

In ip xfrm policy the outbound policy is missing. Therefore it is not surprise that your output packets are in the clear. Are there any error messages in the log while installing the outbound policy? Actually you shouldn't use IPsec transport mode in the presence of NAT anyway.

I don't see any IKEv1 negotiations in strongswan2.log

No longer possible to upload attachements !!!

Yes we are aware of the problem and are working on it.

Update: File uploading should work now.

linux_kernel_ops->raw_eroute = netlink_raw_eroute; (kernel_netlink.c, 1314)
calls netlink_policy() (kernel_netlink.c, 345)
calls send_netlink_msg(hdr, &rsp.n, sizeof(rsp), "policy", text_said) // 356

which returns:

netlink XFRM_MSG_NEWPOLICY response for flow tun.10000@192.168.1.10 included errno 0: Success
netlink XFRM_MSG_NEWPOLICY response for flow esp.2f22974@192.168.1.1 included errno 0: Success

..but

[root@trixi /usr/src/strongswan-4.3.6rc2]#ip xfrm policy 
    ...
    src ::/0 dst ::/0 
            dir 4 priority 0 ptype main 
    src 192.168.1.1/32 dst 62.101.205.112/32 proto udp sport 1701 
            dir in priority 2080 ptype main 
            tmpl src 0.0.0.0 dst 0.0.0.0
                    proto esp reqid 16393 mode transport

[root@trixi /usr/src/strongswan-4.3.6rc2]#ip xfrm state
    src 192.168.1.1 dst 192.168.1.10
            proto esp spi 0x81712fd7 reqid 16393 mode transport
            replay-window 32 
            auth hmac(md5) 0x776110555e59954768a98f96fc8d20f0
            enc cbc(des3_ede) 0x35d5db7167e2be76aef6a84cbcedbf005bc37c9853b26194
            encap type espinudp sport 4500 dport 4500 addr 0.0.0.0
            sel src 0.0.0.0/0 dst 0.0.0.0/0 
    src 192.168.1.10 dst 192.168.1.1
            proto esp spi 0xe195e952 reqid 16393 mode transport
            replay-window 32 
            auth hmac(md5) 0x38263124d912a8822f19fbf481998535
            enc cbc(des3_ede) 0xd9198a7ba8f2d4a66fc9b65869d5ee05b4c64ae1dd062594
            encap type espinudp sport 4500 dport 4500 addr 0.0.0.0
            sel src 0.0.0.0/0 dst 0.0.0.0/0

Seems like send_netlink_msg() fails to setup policy AND fails to detect the failure

Creating my own rules in iptables did not help

I have set up a new server from scratch and installed fc12 and updates
to ensure that there is nothing in my linux intstall that could cause trouble
Also switched to: ipsec version

Linux strongSwan U4.3.6/K2.6.31.12-174.2.22.fc12.i686

Also updated to 4.3.6 on my original strongswan server

After this update the negotiations on both servers stops in 'responding to Quick Mode'
By comparing logs I saw new behavior in this message: '***emit ISAKMP Nonce Payload'

Disabling lines 5073 - 5082 in ./pluto/ipsec_doi.c solved this problem so I presume it's wrong to include '***emit ISAKMP Nonce Payload' in this message (? ..at least against xp)

Delayed update caused me to double post next

Changed and tested my setup without nat and all worked well
Changed and tested with only strongswan-server (responder) behind nat but observe the same behaviour as when both nated:

• IPSec established
• Unencrypted l2tp packets as reply from server

I observe that:

• Leftsourceip or leftsubnet is used as origin/destination for created policies and roules in iptables
• Incoming requests for a tunnel causes the external ip to be used for policy-matching and therefore requires leftsourceip or leftsubnet to be set to the external ip
• All incoming traffic from the client (initiator) arrives with servers internal ip as dest-ip and therefore do not match any policy or iptable-roule based on external ip

It seems more logical to me to set leftsubnet to the internal subnet left is part of and use internal nat'ed ip as origin/destination when matching policies

Changed source in ./pluto/connections.c according to my last update:

function find_client_connection()
    line 3897, added: our_net = &c->spd.this.client;

our_net holds external nated ip when passed to find_client_connection() but packets from initiating xp-client always arrives on responding openswan-server with servers local ip as destination-ip (also when server recides behind nat)

function fc_try()
    line 3649    :    if (!samesubnet(&sr->this.client, our_net))
    replaced by    :    if (!subnetinsubnet(our_net, &sr->this.client))

Original check on line 3649 implies that leftsubnet must match sr->this.client (including mask 32), making leftsubnet meaningless and superfluous
New check allowes eg. leftsubnet to be a subnet without causing a host address to fail

I have observed that policy-matching uses 'left' if 'leftsubnet' or 'leftsourceip' is not given or if left is within leftsubnet (?)
(eg. left=192.168.1.10 and leftsubnet=192.168.1.0/24)

Based on this I have come to the conclusion that leftsourceip is realy meaningless and superfluous and removed it from my conf

UPDATE:

leftsourceip/leftsubnet is superfluous in relation to connection selection but not in relation to created iptable roules and policies

The combined result is that I now (using same connection) can connect:

• Not nated xp-client to not nated strongswan-server
• Not nated xp-client to nated strongswan-server
• Nated xp-client to nated strongswan-server

(Nated xp-client to not nated strongswan-server is not possible and should be tested by another client)

As mentioned before, I'm not an ipsec-expert and there may be implications I do not see so your opinion will be greatly appreciated

I have not been working on this for a long time but my previous post states:

_The combined result is that I now (using same connection) can connect:

Not nated xp-client to not nated strongswan-server
    Not nated xp-client to nated strongswan-server
    Nated xp-client to nated strongswan-server
_
So the answer is Yes