strongSwan

Tobias Brunner wrote:

I am using an older version of strongswan as we need NAT-T to be disabled

Please consider updating. We don't really provide any support for the old IKEv1 implementation anymore. And why that need to disable NAT-T? Why would you even use IKEv1 if you run strongSwan on both ends?

To configure the traffic selectors just configure them appropriately in left|rightsubnet. If the route installation is a problem you could disable that (not sure if that was possible back then), and install routes yourself, if needed. Also, please provide more information (configs, logs, etc.).

We need to disable NAT-T as we are trying an ALG for IPSec and we are using strongswan as IPSec Clients which don't support NAT-T.
I would update the configs and the error logs.

IPSec Clients which don't support NAT-T.

So no NAT-T will be negotiated. Or do they actually have a problem with the proposed NAT-T VID?

Tobias Brunner wrote:

IPSec Clients which don't support NAT-T.

So no NAT-T will be negotiated. Or do they actually have a problem with the proposed NAT-T VID?

Yes, NAT would not be negotiated. Strongswan would act as legacy IPSec Client where NAT is not even supported.

IPSec Clients which don't support NAT-T.

So no NAT-T will be negotiated. Or do they actually have a problem with the proposed NAT-T VID?

Yes, NAT would not be negotiated. Strongswan would act as legacy IPSec Client where NAT is not even supported.

But for that you don't need to disable NAT-T with the legacy nat_traversal settin. If the peer does not reply with the NAT-T VID the feature will be disabled automatically. There should really be no reason to use such an old version.

Tobias Brunner wrote:

IPSec Clients which don't support NAT-T.

So no NAT-T will be negotiated. Or do they actually have a problem with the proposed NAT-T VID?

Yes, NAT would not be negotiated. Strongswan would act as legacy IPSec Client where NAT is not even supported.

But for that you don't need to disable NAT-T with the legacy nat_traversal settin. If the peer does not reply with the NAT-T VID the feature will be disabled automatically. There should really be no reason to use such an old version.

No, Peer would have NAT-T enabled in it. It would have to handle both Legacy IPSec Clients and also Clients which has NAT-T enabled in them. Since, we would be having a NAT in between the peers, the remote endpoint, would always receive the packets in some NATTed port and not in 500. Our remote peer is also strongswan and it does not accept any IKE messages received in other ports, except for 500 if NAT-T is disabled in it.
So I am left with no other option, other than enabling NAT-T in server and disabling NAT-T in client.

ipsec.conf from Client Side:

config setup
     crlcheckinterval=600
     cachecrls=yes
     charonstart=no
     plutostart=yes
     plutodebug=control
     plutostderrlog=/var/log/pluto.log
     strictcrlpolicy=no
     nat_traversal=no

conn %default
     ike=aes128-sha1-modp2048!
     esp=aes128-sha1!
     ikelifetime=60m
     keylife=30m
     rekeymargin=3m
     rekeyfuzz=50%
     keyexchange=ikev1
     mobike=no
     auto=add
     type=tunnel
     pfs=no

conn conn1
     left=10.1.1.1
     leftid="C=IN, O=citrix, CN=RAC1" 
     leftsubnet=10.4.1.1/32
     leftcert=RAC1Cert.der
     leftfirewall=yes
     leftsourceip=%config
     right=10.3.1.1
     rightsubnet=10.5.1.0/24
     rightid="C=IN, O=citrix, CN=server1 --san fedora1.ipsec2.com" 

conn conn2
     left=10.1.1.2
     leftid="C=IN, O=citrix, CN=RAC2" 
     leftsubnet=10.4.1.2/32
     leftcert=RAC2Cert.der
     leftfirewall=yes
     leftsourceip=%config
     right=10.3.1.1
     rightsubnet=10.5.1.0/24
     rightid="C=IN, O=citrix, CN=server1 --san fedora1.ipsec2.com" 

ipsec.secrets in Client Side:

: RSA client1Key.der
10.1.1.1 10.3.1.1 : RSA RAC1Key.der
10.1.1.2 10.3.1.1 : RSA RAC2Key.der
10.1.1.3 10.3.1.1 : RSA RAC3Key.der

When Starting 1st Connection

[root@fedora1 etc]# ipsec up conn1
002 "conn1" #1: initiating Main Mode
102 "conn1" #1: STATE_MAIN_I1: initiate
003 "conn1" #1: received Vendor ID payload [strongSwan]
003 "conn1" #1: received Vendor ID payload [XAUTH]
003 "conn1" #1: received Vendor ID payload [Dead Peer Detection]
104 "conn1" #1: STATE_MAIN_I2: sent MI2, expecting MR2
002 "conn1" #1: we have a cert and are sending it upon request
106 "conn1" #1: STATE_MAIN_I3: sent MI3, expecting MR3
002 "conn1" #1: Peer ID is ID_DER_ASN1_DN: 'C=IN, O=citrix, CN=server1 --san fedora1.ipsec2.com'
002 "conn1" #1: crl not found
002 "conn1" #1: certificate status unknown
002 "conn1" #1: ISAKMP SA established
004 "conn1" #1: STATE_MAIN_I4: ISAKMP SA established
002 "conn1" #1: sending ModeCfg request
002 "conn1" #1: parsing ModeCfg reply
002 "conn1" #1: setting virtual IP source address to 10.1.1.2
002 "conn1" #1: received ModeCfg reply, established
004 "conn1" #1: STATE_MODE_CFG_I2: received ModeCfg reply, established
002 "conn1" #2: initiating Quick Mode PUBKEY+ENCRYPT+TUNNEL+UP {using isakmp#1}
110 "conn1" #2: STATE_QUICK_I1: initiate
002 "conn1" #2: route-client output: /usr/libexec/ipsec/_updown: doroute `ip route add 10.5.1.0/24 via 10.3.1.1 dev eth1:1  src 10.1.1.2 table 220' failed (RTNETLINK answers: Netwo
002 "conn1" #2: sent QI2, IPsec SA established {ESP=>0xc32dd291 <0xce46b49a}
004 "conn1" #2: STATE_QUICK_I2: sent QI2, IPsec SA established {ESP=>0xc32dd291 <0xce46b49a}
[root@fedora1 etc]# 

[root@fedora1 etc]# ipsec up conn2
002 "conn2" #6: initiating Main Mode
102 "conn2" #6: STATE_MAIN_I1: initiate
003 "conn2" #6: received Vendor ID payload [strongSwan]
003 "conn2" #6: received Vendor ID payload [XAUTH]
003 "conn2" #6: received Vendor ID payload [Dead Peer Detection]
104 "conn2" #6: STATE_MAIN_I2: sent MI2, expecting MR2
002 "conn2" #6: we have a cert and are sending it upon request
106 "conn2" #6: STATE_MAIN_I3: sent MI3, expecting MR3
002 "conn2" #6: Peer ID is ID_DER_ASN1_DN: 'C=IN, O=citrix, CN=server1 --san fedora1.ipsec2.com'
002 "conn2" #6: crl not found
002 "conn2" #6: certificate status unknown
002 "conn2" #6: ISAKMP SA established
004 "conn2" #6: STATE_MAIN_I4: ISAKMP SA established
002 "conn2" #6: sending ModeCfg request
002 "conn2" #6: parsing ModeCfg reply
002 "conn2" #6: setting virtual IP source address to 10.1.1.1
002 "conn2" #6: received ModeCfg reply, established
004 "conn2" #6: STATE_MODE_CFG_I2: received ModeCfg reply, established
002 "conn2" #7: initiating Quick Mode PUBKEY+ENCRYPT+TUNNEL+UP {using isakmp#6}
110 "conn2" #7: STATE_QUICK_I1: initiate
003 "conn2" #7: cannot route -- route already in use for "conn1" 
032 "conn2" #7: STATE_QUICK_I1: internal error

ipsec.conf in the Server Side

config setup
        crlcheckinterval=180
    cachecrls=yes
    plutostart=yes
        charonstart=no
    uniqueids=no
        plutodebug=control
        plutostderrlog=/var/log/pluto.log
        strictcrlpolicy=no
        nat_traversal=yes

conn %default
    ike=aes128-sha1-modp2048!
    esp=aes128-sha1!
    ikelifetime=60m
    keylife=30m
    rekeymargin=3m
    rekeyfuzz=50%
    keyingtries=1
    keyexchange=ikev1
        type=tunnel
        pfs=no

conn rw
    left=10.3.1.1
    leftcert=server1Cert.der
    leftid="C=IN, O=citrix, CN=server1 --san fedora1.ipsec2.com" 
    leftsubnet=10.5.1.0/24
    right=%any
        rightsubnetwithin=10.4.0.0/16
        rightsourceip=10.1.1.0/24
    auto=add

Why do you set leftsourceip=%config? Do you actually need virtual IPs in your scenario? The server apparently assigns the same IP, which then causes duplicate IPsec policies. To avoid that you must probably use different identities for the two connections (I guess that depends on the responder's configuration).

Tobias Brunner wrote:

Why do you set leftsourceip=%config? Do you actually need virtual IPs in your scenario? The server apparently assigns the same IP, which then causes duplicate IPsec policies. To avoid that you must probably use different identities for the two connections (I guess that depends on the responder's configuration).

I actually don't need virtual IPs in my scenario. However, the server in my case is not assigning same IP. It has assigned different IPs only if you can see from the logs which I pasted(10.1.1.2 for conn1 and 10.1.1.1 for conn2). Also, I am using different identities only for both the connections. The certs and IDs are different for both of the connections.

It has assigned different IPs only if you can see from the logs which I pasted(10.1.1.2 for conn1 and 10.1.1.1 for conn2).

Hm, true. I only noticed the use of virtual IPs and the error message in the second log and remembered that pluto called the IPsec policies routes and assumed a conflicting policy due to a duplicate VIP. Pluto actually called IPsec policies eroutes, the error here is, in fact, related to regular network routes. It is apparently logged if the remote subnet is the same (i.e. there would be a conflicting route added to the routing table) while the outbound interface and/or nexthop are different (if they weren't the new connection would "steal" the previous route from the first connection, according to the comment in the old source code). So pluto doesn't really support this scenario, because you can't disable that check without code changes.

Tobias Brunner wrote:

It has assigned different IPs only if you can see from the logs which I pasted(10.1.1.2 for conn1 and 10.1.1.1 for conn2).

Hm, true. I only noticed the use of virtual IPs and the error message in the second log and remembered that pluto called the IPsec policies routes and assumed a conflicting policy due to a duplicate VIP. Pluto actually called IPsec policies eroutes, the error here is, in fact, related to regular network routes. It is apparently logged if the remote subnet is the same (i.e. there would be a conflicting route added to the routing table) while the outbound interface and/or nexthop are different (if they weren't the new connection would "steal" the previous route from the first connection, according to the comment in the old source code). So pluto doesn't really support this scenario, because you can't disable that check without code changes.

Thanks for looking into this. Is there a way to disable NAT-T in charon? or any other work-around where I can achieve this scenario in the later versions of strongswan?

Is there a way to disable NAT-T in charon?

Not without code changes (see also #1265). But what exactly is your problem with NAT-T? What is the use case that prevents you from enabling it?

Tobias Brunner wrote:

Is there a way to disable NAT-T in charon?

Not without code changes (see also #1265). But what exactly is your problem with NAT-T? What is the use case that prevents you from enabling it?

As mentioned earlier, we are using strongswan in place of legacy ipsec clients which do not have NAT-T support in them. This is our requirement. I suppose, in later versions of strongswan we have load-tester which can vary the source IPs and also in charon, we have an option to prevent it from installing routes - install_routes=no

Is there a way to disable NAT-T in charon?

Not without code changes (see also #1265). But what exactly is your problem with NAT-T? What is the use case that prevents you from enabling it?

As mentioned earlier, we are using strongswan in place of legacy ipsec clients which do not have NAT-T support in them.

That's what I don't get. If they don't support NAT-T then there will be no NAT-T used between the two peers. That's the whole point of negotiating it by exchanging vendor ID payloads. It basically gets disabled automatically.

I suppose, in later versions of strongswan we have load-tester which can vary the source IPs

I don't see how load-tester is related to this scenario at all.

and also in charon, we have an option to prevent it from installing routes - install_routes=no

Correct.

Tobias Brunner wrote:

IPSec Clients which don't support NAT-T.

So no NAT-T will be negotiated. Or do they actually have a problem with the proposed NAT-T VID?

Yes, NAT would not be negotiated. Strongswan would act as legacy IPSec Client where NAT is not even supported.

But for that you don't need to disable NAT-T with the legacy nat_traversal settin. If the peer does not reply with the NAT-T VID the feature will be disabled automatically. There should really be no reason to use such an old version.

In Strongswan, can we disable replying with NAT-T VID ?

In Strongswan, can we disable replying with NAT-T VID ?

If none are sent by the initiator, none will be contained in the reply.