I am setting up a site-to-site VPN between EdgeRouter and StrongSwan (Linux strongSwan U5.6.2)

My EdgeRouter is behind a NAT.

I see that in the result EdgeOS ipsec.conf there is a setting auto=route. But I do not see this setting as configurable in configure setup.

There is another setting dpdaction=restart which I can't find under configure

According to this article StrongSwan developer recommends to use

• dpdaction=clear
• auto=route (which is already set in EdgeOS by default, I guess)

Let me describe the issue itself:

This setup works only when I run ipsec up <conn_name> on the StrongSwan side or there are some packets intiated from the StrongSwan sent to the EdgeRouter and this data traffic establishes a VPN connection automatically.

But for some reasons it is not possible to initiate/establish a VPN connection from the EdgeRouter side, even though I have set up connection-type=initiate

Ping from StrongSwan initiates/establishes a VPN connection, but not pinging from the EdgeRouter to the StrongSwan.

ipsec restart (on the StrongSwan) brings this VPN sonnection down (but VPN connection with Cisco RV042 is always restored... though this device has some other issues and needs to be replaced)

I am trying to find a replacement for Cisico RV042 and need absolutely to be sure that VPN connections are reliable and stable. ipsec up/restart is not an option in my case.

Any ideas?

im trying to make the script work but im getting these errors as soon as i start the script, anyone know what's happening? i made sure to chmod 0755 the file too

root@ERX-Sanctuary:/config/openvpn# bash ./openvpnserver-config.sh
./openvpnserver-config.sh: line 2: $'\r': command not found
./openvpnserver-config.sh: line 5: $'\r': command not found
./openvpnserver-config.sh: line 10: $'\r': command not found
./openvpnserver-config.sh: line 15: $'\r': command not found
./openvpnserver-config.sh: line 20: $'\r': command not found
./openvpnserver-config.sh: line 22: $'\r': command not found
./openvpnserver-config.sh: line 25: $'\r': command not found
./openvpnserver-config.sh: line 26: syntax error near unexpected token `$'{\r''
'/openvpnserver-config.sh: line 26: `function makeCA () {

---

 wrote:

1. Static mapping of a DHCP-assigned address to a particular client MAC address.  In this case, the IPv4 address needs to be inside the DHCP server's address pool

 

---

First, obviously it doesn't need to be inside the dynamic pool range. Afaik, the common practice is to define static mappings outside this range, and I have done so on various routers, including edgerouters and it works flawlessly.

Here is another thread on the subject:

https://community.ubnt.com/t5/EdgeRouter/Static-Map-outside-of-DHCP-Pool-Range/td-p/2098430

Now the question is, can it be inside the dynamic pool range (and even if it can why would you want this?).

The thread I linked above claims that the "edgerouter" is smart enough to avoid IP collisions in such a case but I am not sure at all this is the case (also it doesn't specify if we are talking about dhcpd or dnsmasq or both). If you have definitive references regarding the edgerouter's dhcpd and/or dnsmasq dhcp servers I would appreciate if you would share them.

By default the edgerouter uses dhcpd as the dhcp server, and I beleive that dhcpd does not support such a configuration properly:

https://docs.netgate.com/pfsense/en/latest/dhcp/static-mappings-inside-dhcp-pools.html

I have also seen such collisions when setting a static mapping inside the dynamic address pool on consumer routers (so the rational in the above thread I linked that it is "inconceivable" that an implementation would not support this is not true).

To make a long story short. My Site to Site has been working for a long time between my two sites. With a bone headed move, both routers got clobbered and I had to restore both routers from a backup. Yes, the backups were recent.

Everything works, however both sites IPSEC Status shows CONNECTING. Here is what I know:

1) I validated both internet facing IP's. Both Ping and Traceroute shows that they work. I have also done this via the Toolbox on EdgeMax OS.

2) H Site is an ER-4 running v1.10.9 (I did note some changes on the subnets on this version)

3) C Site is an ER-Line running v1.9.7+hotfix.2

4) I have attached the configs for both H and C.

5) I did watch sudo swanctl --log for both sites and it seems that the issue is that it is doing a lot of retransmits. Like this:

06[IKE] received retransmit of request with ID 0, retransmitting response
06[NET] sending packet: from 192.225.176.79[500] to 98.202.96.65[500] (136 bytes)
14[IKE] sending retransmit 4 of request message ID 0, seq 1
14[NET] sending packet: from 192.225.176.79[500] to 98.202.96.65[500] (156 bytes)
10[JOB] deleting half open IKE_SA after timeout
01[NET] received packet: from 98.202.96.65[500] to 192.225.176.79[500] (156 bytes)
01[ENC] parsed ID_PROT request 0 [ SA V V V V ]
01[IKE] received XAuth vendor ID
01[IKE] received DPD vendor ID
01[IKE] received NAT-T (RFC 3947) vendor ID
01[IKE] received draft-ietf-ipsec-nat-t-ike-02\n vendor ID
01[IKE] 98.202.96.65 is initiating a Main Mode IKE_SA
01[ENC] generating ID_PROT response 0 [ SA V V V ]
01[NET] sending packet: from 192.225.176.79[500] to 98.202.96.65[500] (136 bytes)
05[IKE] sending retransmit 5 of request message ID 0, seq 1
05[NET] sending packet: from 192.225.176.79[500] to 98.202.96.65[500] (156 bytes)
02[JOB] deleting half open IKE_SA after timeout
15[NET] received packet: from 98.202.96.65[500] to 192.225.176.79[500] (156 bytes)
15[ENC] parsed ID_PROT request 0 [ SA V V V V ]
15[IKE] received XAuth vendor ID
15[IKE] received DPD vendor ID
15[IKE] received NAT-T (RFC 3947) vendor ID
15[IKE] received draft-ietf-ipsec-nat-t-ike-02\n vendor ID
15[IKE] 98.202.96.65 is initiating a Main Mode IKE_SA
15[ENC] generating ID_PROT response 0 [ SA V V V ]
15[NET] sending packet: from 192.225.176.79[500] to 98.202.96.65[500] (136 bytes)
14[JOB] deleting half open IKE_SA after timeout
03[IKE] giving up after 5 retransmits

6) Here is the IPSEC Status All for both sites:

HSite IPSEC StatusAll:

Status of IKE charon daemon (strongSwan 5.2.2, Linux 3.10.107-UBNT, mips64):
uptime: 96 minutes, since Apr 27 07:35:08 2019
malloc: sbrk 376832, mmap 0, used 289416, free 87416
worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 1
loaded plugins: charon ldap sqlite pkcs11 aes des sha1 sha2 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs8 pem openssl agent xcbc cmac ctr ccm gcm curl attr kernel-netlink resolve socket-default stroke vici updown eap-identity eap-md5 eap-mschapv2 eap-radius eap-tls xauth-generic xauth-eap addrblock
Listening IP addresses:
98.202.96.65
172.22.22.1
172.22.23.1
Connections:
peer-ccc.mycompany.com-tunnel-1: %any...ccc.mycompany.com IKEv1
peer-ccc.mycompany.com-tunnel-1: local: [ccc.mycompany.com] uses public key authentication
peer-ccc.mycompany.com-tunnel-1: cert: "ccc.mycompany.com"
peer-ccc.mycompany.com-tunnel-1: remote: [hhh.mycompany.com] uses public key authentication
peer-ccc.mycompany.com-tunnel-1: cert: "hhh.mycompany.com"
peer-ccc.mycompany.com-tunnel-1: child: 172.22.22.0/24 === 172.22.26.0/24 TUNNEL
peer-ccc.mycompany.com-tunnel-2: child: 172.22.23.0/24 === 172.22.26.0/24 TUNNEL
peer-ccc.mycompany.com-tunnel-3: child: 172.22.22.0/24 === 172.22.25.0/24 TUNNEL
peer-ccc.mycompany.com-tunnel-4: child: 172.22.23.0/24 === 172.22.25.0/24 TUNNEL
remote-access: 98.202.96.65...%any IKEv1, dpddelay=15s
remote-access: local: [98.202.96.65] uses pre-shared key authentication
remote-access: remote: uses pre-shared key authentication
remote-access: child: dynamic[udp/l2f] === dynamic[udp] TRANSPORT, dpdaction=clear
Routed Connections:
peer-ccc.mycompany.com-tunnel-4{8}: ROUTED, TUNNEL
peer-ccc.mycompany.com-tunnel-4{8}: 172.22.23.0/24 === 172.22.25.0/24
peer-ccc.mycompany.com-tunnel-3{7}: ROUTED, TUNNEL
peer-ccc.mycompany.com-tunnel-3{7}: 172.22.22.0/24 === 172.22.25.0/24
peer-ccc.mycompany.com-tunnel-2{6}: ROUTED, TUNNEL
peer-ccc.mycompany.com-tunnel-2{6}: 172.22.23.0/24 === 172.22.26.0/24
peer-ccc.mycompany.com-tunnel-1{5}: ROUTED, TUNNEL
peer-ccc.mycompany.com-tunnel-1{5}: 172.22.22.0/24 === 172.22.26.0/24
Security Associations (1 up, 0 connecting):
peer-ccc.mycompany.com-tunnel-1[1]: CONNECTING, 98.202.96.65[%any]...192.225.176.79[%any]
peer-ccc.mycompany.com-tunnel-1[1]: IKEv1 SPIs: 26cb498f48c9cdc5_i* 0000000000000000_r
peer-ccc.mycompany.com-tunnel-1[1]: Tasks queued: QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE
peer-ccc.mycompany.com-tunnel-1[1]: Tasks active: ISAKMP_VENDOR ISAKMP_CERT_PRE MAIN_MODE ISAKMP_CERT_POST ISAKMP_NATD

CSITE IPSEC StatusAll:

Status of IKE charon daemon (strongSwan 5.2.2, Linux 3.10.20-UBNT, mips64):
uptime: 63 minutes, since Apr 27 07:35:23 2019
malloc: sbrk 373904, mmap 0, used 285528, free 88376
worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 1
loaded plugins: charon ldap sqlite pkcs11 aes des sha1 sha2 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs8 pem openssl agent xcbc cmac ctr ccm gcm curl attr kernel-netlink resolve socket-default stroke vici updown eap-identity eap-md5 eap-mschapv2 eap-radius eap-tls xauth-generic xauth-eap addrblock
Listening IP addresses:
172.22.26.1
172.22.25.1
192.225.176.79
Connections:
peer-hhh.mycompany.com-tunnel-1: %any...hhh.mycompany.com IKEv1
peer-hhh.mycompany.com-tunnel-1: local: [hhh.mycompany.com] uses public key authentication
peer-hhh.mycompany.com-tunnel-1: cert: "hhh.mycompany.com"
peer-hhh.mycompany.com-tunnel-1: remote: [ccc.mycompany.com] uses public key authentication
peer-hhh.mycompany.com-tunnel-1: cert: "ccc.mycompany.com"
peer-hhh.mycompany.com-tunnel-1: child: 172.22.26.0/24 === 172.22.22.0/24 TUNNEL
peer-hhh.mycompany.com-tunnel-2: child: 172.22.26.0/24 === 172.22.23.0/24 TUNNEL
peer-hhh.mycompany.com-tunnel-3: child: 172.22.25.0/24 === 172.22.22.0/24 TUNNEL
peer-hhh.mycompany.com-tunnel-4: child: 172.22.25.0/24 === 172.22.23.0/24 TUNNEL
remote-access: 192.225.176.79...%any IKEv1, dpddelay=15s
remote-access: local: [192.225.176.79] uses pre-shared key authentication
remote-access: remote: uses pre-shared key authentication
remote-access: child: dynamic[udp/l2f] === dynamic[udp] TRANSPORT, dpdaction=clear
Routed Connections:
peer-hhh.mycompany.com-tunnel-4{8}: ROUTED, TUNNEL
peer-hhh.mycompany.com-tunnel-4{8}: 172.22.25.0/24 === 172.22.23.0/24
peer-hhh.mycompany.com-tunnel-3{7}: ROUTED, TUNNEL
peer-hhh.mycompany.com-tunnel-3{7}: 172.22.25.0/24 === 172.22.22.0/24
peer-hhh.mycompany.com-tunnel-2{6}: ROUTED, TUNNEL
peer-hhh.mycompany.com-tunnel-2{6}: 172.22.26.0/24 === 172.22.23.0/24
peer-hhh.mycompany.com-tunnel-1{5}: ROUTED, TUNNEL
peer-hhh.mycompany.com-tunnel-1{5}: 172.22.26.0/24 === 172.22.22.0/24
Security Associations (1 up, 0 connecting):
peer-hhh.mycompany.com-tunnel-1[1]: CONNECTING, 192.225.176.79[%any]...98.202.96.65[%any]
peer-hhh.mycompany.com-tunnel-1[1]: IKEv1 SPIs: 7b3dd9469bfe2980_i* 0000000000000000_r
peer-hhh.mycompany.com-tunnel-1[1]: Tasks queued: QUICK_MODE QUICK_MODE
peer-hhh.mycompany.com-tunnel-1[1]: Tasks active: ISAKMP_VENDOR ISAKMP_CERT_PRE MAIN_MODE ISAKMP_CERT_POST ISAKMP_NATD

I am hoping that someone might have an idea on why they just won't connect, when 2 days ago that were connecting fine with this configuration.

Thanks!
Dave...

You say "My EdgeRouter is behind a NAT", assuming this is not a NAT you control (and can forward the relavent ports), the connection can only be initiated by this side (meaning from the side which is behind the NAT to the site which is not behind a NAT). If I understand you correctly you claim the opposite which does not make sense. If necessary read about IP connections and NATs (for example start with this and this and this).

If your VPN server is behind a NAT which you do control, you need to forward the appropriate ports:

https://help.ubnt.com/hc/en-us/articles/216771078-EdgeRouter-Modifying-the-Default-IPsec-Site-to-Sit...

In step 2 they detail the required ports which are opened on the edgerouter firewall. These same ports need to be forwarded to the edgerouter.

Regarding the "auto=route" ipsec.conf options, afaik, using the edgerouter configuration that is the only option.

Regarding the "dpdaction=restart" (or "dpdaction=clear") you can set that from the configure, see step 7 in the above link.

Assuming one of the VPN sides is behind a NAT (which does not forward ports), see this article:

https://help.ubnt.com/hc/en-us/articles/115013382567-EdgeRouter-IPsec-Site-to-Site-VPN-behind-NAT

I would also set the side which is behind the NAT to "initiate" ("set vpn ipsec site-to-site peer <side.without.nat> connection-type initiate") and the dpdaction to "restart". On the side which is not behind NAT I would set the connection-type to "respond" and dpdaction to "clear" (as you can not connect to the side behind the NAT).

Seems like RouterA has 2 external links.

Use PBR to steer specific traffic (here tcp dest port 1234) towards WANx interface

https://help.ubnt.com/hc/en-us/articles/204952274-EdgeRouter-Policy-Based-Routing

I guess, I have figured it out.

It was an authentication issue when connection was initiated from the EdgeRouter side. My configuration was missing id (leftid) which in my case is a FQDN (StrongSwan configuration has it as the corresponding rightid).
I am not an ipsec expert. Is this id authentication/verification initiated only by the right side of the VPN connection?

Why I was able to establish a VPN connection from the left (StriongSwan) , although the right side (EdgeRouter) was missing id.

First, I hope those logs and configs are anonymized. If those are your real hostnames and addresses you should remove them ASAP and/or replace them with sanitized versions.

From a quick look at your config, it looks like you are using FQDNs with rsa certificates but have small discrepancies from the guide:

https://help.ubnt.com/hc/en-us/articles/115011373628

For example I notice you are missing the "@" in the authentication id and remote-id (I admit I never actually tried without the "@").

Additionally, I see you are using "local-address any" which I am not sure about (I think "any" should work at least for the DHCP side but not 100% sure). The side which uses a DHCP WAN connection should do (taken from the above guide):

delete vpn ipsec site-to-site peer er-l.ubnt.com local-address
set vpn ipsec site-to-site peer er-l.ubnt.com dhcp-interface eth0

The side with the pppoe connection should do:

set vpn ipsec site-to-site peer 192.0.2.1 local-address 0.0.0.0

(taken from here; I could also swear that this guide once had specific instruction about this).

Also I am not sure about the side which is running v1.9.7, this is quite an old version and possibly things which now work with v1.10.9 did not work on this version (I am afraid I have no experience with such old versions).

If you are still having trouble please post sanitized versions of the full "sudo swanctl --log" from both sides when issuing the following from one the sides:

clear vpn ipsec-peer <other.side>

(meaning first run "sudo swanctl --log" on both sides and leave it running, then issue the command and capture the output it generates)

From the partial and one sided log you provided it looks like that side is transmiting packets to the other side but is not getting any response. Without the log of the other side it is impossible to tell if the other side got these packets and did it try to answer.

Finally you say that until two days ago it worked, what changed two days ago or at least recently which may have caused this problem?

eran45, thank you for your explanations.

My EdgeRouter is behind a NAT with port forwarding (test environment). The production router which is going to be repalced (hopefully by EdgeRouter 4) is not behind a NAT, so the NAT is not going to be an issue.

What would you recommend to have in my configurations on strongSwan ( I am using it as a VPN gateway on AWS VPC) and EdgeRouter (office LAN)

I am thinking of this configuration.

StrongSwan:

keyexchange=ikev2

auto=route

dpdaction=clear

EdgeRouter (not behind a NAT):

keyexchange=ikev2

connection-type=initiate

auto=route

dpdaction=clear

I'm having trouble setting up a NAT.  My situation is that I have two networks that have the same starting prefix, but we are running into an issue with the industrial control network sometimes not recieving the right information to set up our industrial process...because the packet which has that information is leaving the wrong interface...

So here's what the system looks like right now...  Clearly not so good to have 2x 10.8.x.x NICs in the same computer, connected to different networks....

So here's what we are trying to do....

Please also note that in the 2nd drawing, I mislabeled ETH0 as ETH1

I've looked at the following resources already-

https://www.youtube.com/watch?v=fPhJ3UyXFsA

&&

https://www.youtube.com/watch?v=YRWnkEUkfs8&

These have been somewhat enlightening, but I still feel like I'm missing something critical.  I'm just fine at setting up Plain-Old switching networks with Cisco / Dell equipment...but this is my 1st foray into routing.

And here's a copy of my edgerouterX configuration...

ubnt@ubnt:~$ show configuration
firewall {
    all-ping enable
    broadcast-ping disable
    ipv6-receive-redirects disable
    ipv6-src-route disable
    ip-src-route disable
    log-martians enable
    name WAN_IN {
        default-action drop
        description "WAN to internal"
        rule 10 {
            action accept
            description "ACCEPT ALL TO 10.8.63.242"
            destination {
                address 10.8.63.242
            }
            log disable
            protocol all
        }
        rule 20 {
            action accept
            description "Allow established/related"
            state {
                established enable
                related enable
            }
        }
        rule 30 {
            action drop
            description "Drop invalid state"
            state {
                invalid enable
            }
        }
    }
    name WAN_LOCAL {
        default-action drop
        description "WAN to router"
        rule 10 {
            action accept
            description "Allow established/related"
            state {
                established enable
                related enable
            }
        }
        rule 20 {
            action drop
            description "Drop invalid state"
            state {
                invalid enable
            }
        }
    }
    receive-redirects disable
    send-redirects enable
    source-validation disable
    syn-cookies enable
}
interfaces {
    ethernet eth0 {
        address 10.8.63.1/32
        address 10.8.63.242/32
        description Internet
        duplex auto
        firewall {
            in {
                name WAN_IN
            }
            local {
                name WAN_LOCAL
            }
        }
        speed auto
    }
    ethernet eth1 {
        address 192.168.2.1/24
        description "Local 2"
        duplex auto
        speed auto
    }
    ethernet eth2 {
        description Local
        duplex auto
        speed auto
    }
    ethernet eth3 {
        description Local
        duplex auto
        speed auto
    }
    ethernet eth4 {
        description Local
        duplex auto
        speed auto
    }
    loopback lo {
    }
    switch switch0 {
        address 192.168.1.1/24
        description Local
        switch-port {
            interface eth2 {
            }
            interface eth3 {
            }
            interface eth4 {
            }
        }
    }
}
service {
    dhcp-server {
        disabled false
        hostfile-update disable
        shared-network-name LAN1 {
            authoritative enable
            subnet 192.168.2.0/24 {
                default-router 192.168.2.1
                dns-server 192.168.2.1
                lease 86400
                start 192.168.2.38 {
                    stop 192.168.2.243
                }
            }
        }
    }
    dns {
        forwarding {
            cache-size 150
            listen-on eth1
            listen-on switch0
        }
    }
    gui {
        https-port 443
    }
    nat {
        rule 1 {
            destination {
                address 10.8.63.242/32
            }
            inbound-interface eth0
            inside-address {
                address 192.168.1.242/32
            }
            log disable
            type destination
        }
        rule 5001 {
            description static
            log disable
            outbound-interface eth0
            outside-address {
                address 10.8.63.242/32
            }
            protocol all
            source {
                address 192.168.1.242/32
            }
            type source
        }
        rule 5010 {
            description "masquerade for WAN"
            outbound-interface eth0
            type masquerade
        }
    }
    ssh {
        port 22
        protocol-version v2
    }
}
system {
    gateway-address 10.8.63.254
    host-name ubnt
    login {
        user ubnt {
            authentication {
                encrypted-password ****************
            }
            level admin
        }
    }
    name-server 8.8.8.8
    ntp {
        server 0.ubnt.pool.ntp.org {
        }
        server 1.ubnt.pool.ntp.org {
        }
        server 2.ubnt.pool.ntp.org {
        }
        server 3.ubnt.pool.ntp.org {
        }
    }
    syslog {
        global {
            facility all {
                level notice
            }
            facility protocols {
                level debug
            }
        }
    }
    time-zone UTC
}
ubnt@ubnt:~$

EDIT:  Also would prefer that any host on the 10.8.63 side should be reachable by the 192.168.1.242 computer by pinging its respective ip address... i.e. 10.8.63.100 should be reachable by the 192.168.1.242 computer at address 192.168.1.100.

Feedback is greatly appreciated.  I'm considering adding a bounty to this...I'm going to do it....  Best solution (and I have the time to test today / tomorrow) gets a $50 chocolate basket, with a card, shipped to anyone in the USA.  My family owns a gourmet chocolate shop... Help me figure this out? 

---

 wrote:

I am not an ipsec expert. Is this id authentication/verification initiated only by the right side of the VPN connection?

---

I am also not an ipsec expert, and it is hard to give a good explaination without seeing the full ipsec.conf of both sides.

Basically, I would expect the side which connects to properly verify the remote side (which was missing the leftid if I understand correctly). I assume that in your case the other values you did have configured were enough for this.

See more information in the documentation for "leftid" here (and specifically that it has a default when not given).

So  Cbell came and isolated to the ethernet cable.       They tested the service to the house (Ftth which terminates to a box on the side of the house) and that was good.      So they put on new connections on the  ethernet.   The ethernet goes from their box to my basement.

I disconnected their ethernet from their gateway to my ERL and it was working great for a few hours.       When I noticed no internet, I opened up the  ERL said it was 'disconnected'.    So I unplugged it and put it back to their gateway, and it was working fine.       Now I have it back connected back to my ERL (without the gateway).

I thought about trying to connect from the gateway, but then I think I need to figure out if/how to make that Xyxel 'gateway' passive???

Why would it disconnect?    Could it be software?      I assume the ERL can handle 1Gb service?         Hardware?

I'm not seeing any messages in my Alert window.         I don't think anything is logging so I'll try to figure out how to set the ERL log too.

This thread has now became so long so anyone please share the best one out of this.

H Configuration attached.

C Configuration Attached.

My technical employee (me) did a real bone head move, that the only way to fix was to restore both routers from a recent backup. Everything is working after the restore, many restarts, except for the site to site.  Also, both of my L2TP vpns are working on both sides.

I applied those suggestions and here is the results (also, uploaded configs after the changes for both sides.)

Changed H (DHCP) = hhh.mycompany.com (hhh.hhh.hhh.hhh)
Changed C (PPOE) = ccc.mycompany.com (ccc.ccc.ccc.ccc)

C (PPOE) clear vpn:

Resetting tunnel 1 with peer hhh.mycompany.com...

H (DHCP) Log is as follows:

03[ENC] not enough input to parse rule 3 U_INT_4
03[ENC] header could not be parsed
03[NET] received invalid IKE header from 193.56.28.124 - ignored

C (PPOE) Log us as follows (let go for about 15 minutes):

10[CFG] received stroke: terminate 'peer-hhh.mycompany.com-tunnel-1'
10[CFG] no IKE_SA named 'peer-hhh.mycompany.com-tunnel-1' found
13[CFG] received stroke: initiate 'peer-hhh.mycompany.com-tunnel-1'
16[IKE] initiating Main Mode IKE_SA peer-hhh.mycompany.com-tunnel-1[1] to hhh.hhh.hhh.hhh
16[ENC] generating ID_PROT request 0 [ SA V V V V ]
16[NET] sending packet: from ccc.ccc.ccc.ccc[500] to hhh.hhh.hhh.hhh[500] (156 bytes)
12[IKE] sending retransmit 1 of request message ID 0, seq 1
12[NET] sending packet: from ccc.ccc.ccc.ccc[500] to hhh.hhh.hhh.hhh[500] (156 bytes)
05[IKE] sending retransmit 2 of request message ID 0, seq 1
05[NET] sending packet: from ccc.ccc.ccc.ccc[500] to hhh.hhh.hhh.hhh[500] (156 bytes)
06[IKE] sending retransmit 3 of request message ID 0, seq 1
06[NET] sending packet: from ccc.ccc.ccc.ccc[500] to hhh.hhh.hhh.hhh[500] (156 bytes)
11[IKE] sending retransmit 4 of request message ID 0, seq 1
11[NET] sending packet: from ccc.ccc.ccc.ccc[500] to hhh.hhh.hhh.hhh[500] (156 bytes)
10[IKE] sending retransmit 5 of request message ID 0, seq 1
10[NET] sending packet: from ccc.ccc.ccc.ccc[500] to hhh.hhh.hhh.hhh[500] (156 bytes)
05[IKE] giving up after 5 retransmits
05[IKE] peer not responding, trying again (2/0)
05[IKE] initiating Main Mode IKE_SA peer-hhh.mycompany.com-tunnel-1[1] to hhh.hhh.hhh.hhh
05[ENC] generating ID_PROT request 0 [ SA V V V V ]
05[NET] sending packet: from ccc.ccc.ccc.ccc[500] to hhh.hhh.hhh.hhh[500] (156 bytes)
04[IKE] sending retransmit 1 of request message ID 0, seq 1
04[NET] sending packet: from ccc.ccc.ccc.ccc[500] to hhh.hhh.hhh.hhh[500] (156 bytes)
09[IKE] sending retransmit 2 of request message ID 0, seq 1
09[NET] sending packet: from ccc.ccc.ccc.ccc[500] to hhh.hhh.hhh.hhh[500] (156 bytes)
16[IKE] sending retransmit 3 of request message ID 0, seq 1
16[NET] sending packet: from ccc.ccc.ccc.ccc[500] to hhh.hhh.hhh.hhh[500] (156 bytes)
05[KNL] creating acquire job for policy 172.22.26.21/32[tcp/53915] === 172.22.22.3/32[tcp/32400] with reqid {1}
04[KNL] creating acquire job for policy 172.22.26.21/32[tcp/53916] === 172.22.23.3/32[tcp/32400] with reqid {2}
09[IKE] sending retransmit 4 of request message ID 0, seq 1
09[NET] sending packet: from ccc.ccc.ccc.ccc[500] to hhh.hhh.hhh.hhh[500] (156 bytes)
12[IKE] sending retransmit 5 of request message ID 0, seq 1
12[NET] sending packet: from ccc.ccc.ccc.ccc[500] to hhh.hhh.hhh.hhh[500] (156 bytes)
10[IKE] giving up after 5 retransmits
10[IKE] peer not responding, trying again (3/0)
10[IKE] initiating Main Mode IKE_SA peer-hhh.mycompany.com-tunnel-1[1] to hhh.hhh.hhh.hhh
10[ENC] generating ID_PROT request 0 [ SA V V V V ]
10[NET] sending packet: from ccc.ccc.ccc.ccc[500] to hhh.hhh.hhh.hhh[500] (156 bytes)
14[IKE] sending retransmit 1 of request message ID 0, seq 1
14[NET] sending packet: from ccc.ccc.ccc.ccc[500] to hhh.hhh.hhh.hhh[500] (156 bytes)
04[IKE] sending retransmit 2 of request message ID 0, seq 1
04[NET] sending packet: from ccc.ccc.ccc.ccc[500] to hhh.hhh.hhh.hhh[500] (156 bytes)
16[IKE] sending retransmit 3 of request message ID 0, seq 1
16[NET] sending packet: from ccc.ccc.ccc.ccc[500] to hhh.hhh.hhh.hhh[500] (156 bytes)
10[IKE] sending retransmit 4 of request message ID 0, seq 1
10[NET] sending packet: from ccc.ccc.ccc.ccc[500] to hhh.hhh.hhh.hhh[500] (156 bytes)
04[IKE] sending retransmit 5 of request message ID 0, seq 1
04[NET] sending packet: from ccc.ccc.ccc.ccc[500] to hhh.hhh.hhh.hhh[500] (156 bytes)
09[IKE] giving up after 5 retransmits
09[IKE] peer not responding, trying again (4/0)
09[IKE] initiating Main Mode IKE_SA peer-hhh.mycompany.com-tunnel-1[1] to hhh.hhh.hhh.hhh
09[ENC] generating ID_PROT request 0 [ SA V V V V ]
09[NET] sending packet: from ccc.ccc.ccc.ccc[500] to hhh.hhh.hhh.hhh[500] (156 bytes)
07[IKE] sending retransmit 1 of request message ID 0, seq 1
07[NET] sending packet: from ccc.ccc.ccc.ccc[500] to hhh.hhh.hhh.hhh[500] (156 bytes)
11[IKE] sending retransmit 2 of request message ID 0, seq 1
11[NET] sending packet: from ccc.ccc.ccc.ccc[500] to hhh.hhh.hhh.hhh[500] (156 bytes)
05[IKE] sending retransmit 3 of request message ID 0, seq 1
05[NET] sending packet: from ccc.ccc.ccc.ccc[500] to hhh.hhh.hhh.hhh[500] (156 bytes)
09[IKE] sending retransmit 4 of request message ID 0, seq 1
09[NET] sending packet: from ccc.ccc.ccc.ccc[500] to hhh.hhh.hhh.hhh[500] (156 bytes)
06[IKE] sending retransmit 5 of request message ID 0, seq 1
06[NET] sending packet: from ccc.ccc.ccc.ccc[500] to hhh.hhh.hhh.hhh[500] (156 bytes)
14[IKE] giving up after 5 retransmits
14[IKE] peer not responding, trying again (5/0)
14[IKE] initiating Main Mode IKE_SA peer-hhh.mycompany.com-tunnel-1[1] to hhh.hhh.hhh.hhh
14[ENC] generating ID_PROT request 0 [ SA V V V V ]
14[NET] sending packet: from ccc.ccc.ccc.ccc[500] to hhh.hhh.hhh.hhh[500] (156 bytes)
07[IKE] sending retransmit 1 of request message ID 0, seq 1
07[NET] sending packet: from ccc.ccc.ccc.ccc[500] to hhh.hhh.hhh.hhh[500] (156 bytes)
06[IKE] sending retransmit 2 of request message ID 0, seq 1
06[NET] sending packet: from ccc.ccc.ccc.ccc[500] to hhh.hhh.hhh.hhh[500] (156 bytes)
04[IKE] sending retransmit 3 of request message ID 0, seq 1
04[NET] sending packet: from ccc.ccc.ccc.ccc[500] to hhh.hhh.hhh.hhh[500] (156 bytes)
14[IKE] sending retransmit 4 of request message ID 0, seq 1
14[NET] sending packet: from ccc.ccc.ccc.ccc[500] to hhh.hhh.hhh.hhh[500] (156 bytes)
12[IKE] sending retransmit 5 of request message ID 0, seq 1
12[NET] sending packet: from ccc.ccc.ccc.ccc[500] to hhh.hhh.hhh.hhh[500] (156 bytes)

Thanks for looking at this!

Thanks!

Dave...

---

 wrote:

What would you recommend to have in my configurations on strongSwan

---

If I understand correctly neither sides will be behind a NAT (or be behind a NAT but with port forwarding which should not be a problem when properly configured). In which case either of the sides should be able to bring up the connection and you can either aim for keeping the tunnel always up or only when necessary.

For example, I use "connection-type=respond" and "dpdaction=clear" which results in the following ipsec.conf parameters:

dpdaction=clear
keyingtries=1 # with connection-type=initiate this is %forever

This will let the tunnel come down until it is accessed (from either side). There is a small delay for the first access until the tunnel comes up but I did not run into any problems (you might see the first ping timeout until the tunnel comes up but for other protocols I have not seen a timeout). Obivously this only works if both sides can bring up the tunnel.

Alternatively, you can use the default "connection-type=initiate" with the "dpdaction=restart" to attempt to keep the tunnel always up. This is the only option when only one side can bring up the tunnel (for the side that can bring up the connection).

Finally also note I have this in my edgerouter config:

set vpn ipsec auto-update 120

I am not sure exactly what this does and whats it's equivalent on the non-edgerouter side. If I remember correctly I added it because I read it is recommended and not because of an actual problem I had.