Header Shadow Image


OpenWRT: Microsoft Azure to Cloudera CDH via VPN Gateway

Pages: 1 2 3 4 5 6 7

ISSUES AND RESOLUTIONS

MESSAGE:

In case you receive the following failure in creating proper tunnels while instantiating a new connection:

Jun 18 10:43:40 DD-WRT-INTERNET-ASUS daemon.info charon: 13[KNL] error installing route with policy 10.0.0.0/24 === 10.1.1.0/24 out

Trying to bring up the tunnels manually, also fails with the same message:

root@DD-WRT-INTERNET-ASUS:~# ipsec up AZURE
establishing CHILD_SA AZURE{2}
generating CREATE_CHILD_SA request 3 [ SA No TSi TSr ]
sending packet: from 123.123.123.123[4500] to 100.100.100.100[4500] (428 bytes)
received packet: from 100.100.100.100[4500] to 123.123.123.123[4500] (348 bytes)
parsed CREATE_CHILD_SA response 3 [ SA No TSi TSr ]
selected proposal: ESP:AES_CBC_256/HMAC_SHA1_96/NO_EXT_SEQ
error installing route with policy 10.0.0.0/24 === 10.1.1.0/24 out
unable to install IPsec policies (SPD) in kernel
failed to establish CHILD_SA, keeping IKE_SA
sending DELETE for ESP CHILD_SA with SPI 3f928902
generating INFORMATIONAL request 4 [ D ]
sending packet: from 123.123.123.123[4500] to 100.100.100.100[4500] (76 bytes)
received packet: from 100.100.100.100[4500] to 123.123.123.123[4500] (76 bytes)
parsed INFORMATIONAL response 4 [ D ]
establishing connection 'AZURE' failed
root@DD-WRT-INTERNET-ASUS:~#

Do the following to remove all but just one subnet:

root@DD-WRT-INTERNET-ASUS:~#
root@DD-WRT-INTERNET-ASUS:~#
root@DD-WRT-INTERNET-ASUS:~# nc 52.188.11.203 500
^C
root@DD-WRT-INTERNET-ASUS:~# ipsec status
Security Associations (1 up, 0 connecting):
       AZURE[1]: ESTABLISHED 4 minutes ago, 123.123.123.123[123.123.123.123]…52.188.11.203[52.188.11.203]
root@DD-WRT-INTERNET-ASUS:~#
root@DD-WRT-INTERNET-ASUS:~#
root@DD-WRT-INTERNET-ASUS:~# ipsec status
Security Associations (1 up, 0 connecting):
       AZURE[1]: ESTABLISHED 5 minutes ago, 123.123.123.123[123.123.123.123]…52.188.11.203[52.188.11.203]
root@DD-WRT-INTERNET-ASUS:~#
root@DD-WRT-INTERNET-ASUS:~#
root@DD-WRT-INTERNET-ASUS:~#
root@DD-WRT-INTERNET-ASUS:~# vi /opt/etc/ipsec.conf
root@DD-WRT-INTERNET-ASUS:~# cp -ip /opt/etc/ipsec.conf /opt/etc/ipsec.conf-backup
root@DD-WRT-INTERNET-ASUS:~# vi /opt/etc/ipsec.conf
root@DD-WRT-INTERNET-ASUS:~#
root@DD-WRT-INTERNET-ASUS:~#
root@DD-WRT-INTERNET-ASUS:~#
root@DD-WRT-INTERNET-ASUS:~# ipsec restart
Stopping strongSwan IPsec…
Starting strongSwan 5.8.2 IPsec [starter]…
root@DD-WRT-INTERNET-ASUS:~#
root@DD-WRT-INTERNET-ASUS:~#
root@DD-WRT-INTERNET-ASUS:~# ipsec status
Security Associations (1 up, 0 connecting):
       AZURE[1]: ESTABLISHED 3 seconds ago, 123.123.123.123[123.123.123.123]…52.188.11.203[52.188.11.203]
       AZURE{1}:  INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: 45504fcd_i ddb68aa2_o
       AZURE{1}:   192.168.0.0/24 === 10.10.0.0/24
root@DD-WRT-INTERNET-ASUS:~#
root@DD-WRT-INTERNET-ASUS:~#

root@DD-WRT-INTERNET-ASUS:~# diff /opt/etc/ipsec.conf /opt/etc/ipsec.conf-backup
19c19
<         leftsubnet=192.168.0.0/24     # Network subnet located on-premises

>         leftsubnet=192.168.0.0/24,10.0.0.0/24,10.1.0.0/24,10.2.0.0/24,10.3.0.0/24     # Network subnet located on-premises
22c22
<         rightsubnet=10.10.0.0/24                      # Azure network subnet defined in cloud

>         rightsubnet=10.10.0.0/24,10.10.1.0/24,10.10.2.0/24,10.10.3.0/24                       # Azure network subnet defined in coud
root@DD-WRT-INTERNET-ASUS:~

 

MESSAGE:

Mismatched authentication types used:

constraint requires public key authentication, but pre-shared key was used    

This is printed if authby=secret is not used or omitted in the block when pre-shared keys are being used. 


MESSAGE:

Missing matching configuration block for traffic received during negotiation:

Oct 23 23:38:10 charon: 08[CFG] looking for peer configs matching 192.168.0.16[100.100.100.100]…192.168.0.6[192.168.0.16]
Oct 23 23:38:10 charon: 08[CFG] looking for peer configs matching 192.168.0.16[100.100.100.100]…192.168.0.6[192.168.0.16]
Oct 23 23:38:10 charon: 08[CFG] no matching peer config found
Oct 23 23:38:10 charon: 08[CFG] no matching peer config found


This means configuration such as this was missing, including the correct left, right, leftid and rightid tags:

conn asus-to-remote
        left=192.168.0.16
        leftid=100.100.100.100
        right=192.168.0.6
        rightid=192.168.0.16

Another way to look at it is that 
        
Oct 23 23:38:10 charon: 08[CFG] looking for peer configs matching left[leftid]…right[rightid]
Oct 23 23:38:10 charon: 08[CFG] no matching peer config found

Ensure you have a correctly defined block.
 

MESSAGE:

Similar to above:

Oct 24 01:49:36 charon: 16[CFG] looking for peer configs matching 192.168.0.16[%any]…192.168.0.6[100.100.100.100]
Oct 24 01:49:36 charon: 16[CFG] looking for peer configs matching 192.168.0.16[%any]…192.168.0.6[100.100.100.100]
Oct 24 01:49:36 charon: 16[CFG] no matching peer config found
Oct 24 01:49:36 charon: 16[CFG] no matching peer config found

Again, a repeat of the second block.  Solved by:

conn asus-any-to-remote
        left=192.168.0.16
        leftid=%any
        right=192.168.0.6
        rightid=123.123.123.123

        leftsubnet=192.168.0.0/24,10.0.0.0/24,10.1.0.0/24,10.2.0.0/24,10.3.0.0/24       # Home LAB – Local
        rightsubnet=10.10.0.0/24,10.10.10.0/24,10.10.20.0/24,10.10.30.0/24              # Remote network subnet


MESSAGE:

Incorrect or missing identity (leftid or rightid) set on a conn stanza:

Oct 24 02:27:30 charon: 12[IKE] authentication of '100.100.100.100' with pre-shared key successful
Oct 24 02:27:30 charon: 12[IKE] authentication of '100.100.100.100' with pre-shared key successful
Oct 24 02:27:30 charon: 12[CFG] constraint check failed: identity '192.168.0.6' required
Oct 24 02:27:30 charon: 12[CFG] constraint check failed: identity '192.168.0.6' required
Oct 24 02:27:30 charon: 12[CFG] selected peer config 'remote-to-asus' unacceptable: constraint checking failed
Oct 24 02:27:30 charon: 12[CFG] selected peer config 'remote-to-asus' unacceptable: constraint checking failed
Oct 24 02:27:30 charon: 12[CFG] no alternative config found
Oct 24 02:27:30 charon: 12[CFG] no alternative config found
Oct 24 02:27:30 charon: 12[ENC] generating INFORMATIONAL request 2 [ N(AUTH_FAILED) ]
Oct 24 02:27:30 charon: 12[ENC] generating INFORMATIONAL request 2 [ N(AUTH_FAILED) ]
Oct 24 02:27:30 charon: 12[NET] sending packet: from 192.168.0.16[4500] to 192.168.0.6[4500] (76 bytes)
Oct 24 02:27:30 charon: 12[NET] sending packet: from 192.168.0.16[4500] to 192.168.0.6[4500] (76 bytes)

Oct 24 03:19:25 charon: 16[IKE] authentication of '100.100.100.100' with pre-shared key successful
Oct 24 03:19:25 charon: 16[IKE] authentication of '100.100.100.100' with pre-shared key successful
Oct 24 03:19:25 charon: 16[CFG] constraint check failed: identity '123.123.123.123' required
Oct 24 03:19:25 charon: 16[CFG] constraint check failed: identity '123.123.123.123' required
Oct 24 03:19:25 charon: 16[CFG] selected peer config 'remote-to-asus' unacceptable: constraint checking failed
Oct 24 03:19:25 charon: 16[CFG] selected peer config 'remote-to-asus' unacceptable: constraint checking failed
 Oct 24 03:19:25 charon: 16[CFG] no alternative config found
Oct 24 03:19:25 charon: 16[CFG] no alternative config found
Oct 24 03:19:25 charon: 16[ENC] generating INFORMATIONAL request 2 [ N(AUTH_FAILED) ]
Oct 24 03:19:25 charon: 16[ENC] generating INFORMATIONAL request 2 [ N(AUTH_FAILED) ]

Deriving from this post https://wiki.strongswan.org/issues/3226, the solution is to properly set the rightid based on the "authentication of '100.100.100.100'".  So leftid must equal 100.100.100.100 and rightid must equal 123.123.123.123.  The right side is our on-prem gateway.  The left side is the Azure VPN therefore must be represented by the correct ID (in this case IP):

conn remote-to-asus
     left=192.168.0.6
     leftid=100.100.100.100
     right=192.168.0.16
     rightid=123.123.123.123

     rightsubnet=192.168.0.0/24,10.0.0.0/24,10.1.0.0/24,10.2.0.0/24,10.3.0.0/24      # Home LAB – Local
     leftsubnet=10.10.0.0/24,10.10.10.0/24,10.10.20.0/24,10.10.30.0/24               # Remote network subnet

You should be greated by once you make the above change:

Oct 24 03:22:36 charon: 15[IKE] authentication of '100.100.100.100' with pre-shared key successful
Oct 24 03:22:36 charon: 15[IKE] authentication of '100.100.100.100' with pre-shared key successful
Oct 24 03:22:36 charon: 15[IKE] IKE_SA remote-to-asus[1] established between 192.168.0.16[123.123.123.123]…192.168.0.6[100.100.100.100]
Oct 24 03:22:36 charon: 15[IKE] IKE_SA remote-to-asus[1] established between 192.168.0.16[123.123.123.123]…192.168.0.6[100.100.100.100]
Oct 24 03:22:36 charon: 15[IKE] scheduling reauthentication in 28521s
Oct 24 03:22:36 charon: 15[IKE] scheduling reauthentication in 28521s
Oct 24 03:22:36 charon: 15[IKE] maximum IKE_SA lifetime 28701s
Oct 24 03:22:36 charon: 15[IKE] maximum IKE_SA lifetime 28701s

 

MESSAGE:

This error means that no acceptable encryption algorithm could be negotiated between the remove and on-prem gateway:
    
        Oct 24 03:22:36 charon: 15[CFG] received proposals: ESP:AES_GCM_16_256/NO_EXT_SEQ
        Oct 24 03:22:36 charon: 15[CFG] received proposals: ESP:AES_GCM_16_256/NO_EXT_SEQ
        Oct 24 03:22:36 charon: 15[CFG] configured proposals: ESP:AES_CBC_256/HMAC_SHA1_96/NO_EXT_SEQ, ESP:AES_CBC_128/AES_CBC_192/AES_CBC_256/HMAC_SHA2_256_128/HMAC_SHA2_384_192/HMAC_SHA2_512_256/HMAC_SHA1_96/AES_XCBC_96/NO_EXT_SEQ, ESP:AES_GCM_16_128/AES_GCM_16_192/AES_GCM_16_256
        Oct 24 03:22:36 charon: 15[CFG] configured proposals: ESP:AES_CBC_256/HMAC_SHA1_96/NO_EXT_SEQ, ESP:AES_CBC_128/AES_CBC_192/AES_CBC_256/HMAC_SHA2_256_128/HMAC_SHA2_384_192/HMAC_SHA2_512_256/HMAC_SHA1_96/AES_XCBC_96/NO_EXT_SEQ, ESP:AES_GCM_16_128/AES_GCM_16_192/AES_GCM_16_256
        Oct 24 03:22:36 charon: 15[IKE] no acceptable proposal found
        Oct 24 03:22:36 charon: 15[IKE] no acceptable proposal found
        Oct 24 03:22:36 charon: 15[IKE] failed to establish CHILD_SA, keeping IKE_SA
        Oct 24 03:22:36 charon: 15[IKE] failed to establish CHILD_SA, keeping IKE_SA
        Oct 24 03:22:36 charon: 15[IKE] sending DELETE for ESP CHILD_SA with SPI eb6a4d32
        Oct 24 03:22:36 charon: 15[IKE] sending DELETE for ESP CHILD_SA with SPI eb6a4d32

Ensure the default section includes aes256gcm16 to match the received proposals ESP:AES_GCM_16_256/NO_EXT_SEQ . Notice how it is indicating ESP, meaning you'll need to update the esp= line.  


        conn %default
             .
             .
             .
             .
             .

            ike=aes256-sha1-modp1024
            esp=aes256gcm16,aes256-sha1


MESSAGE:

In this case, the fix is similar to the earlier one:

        Oct 24 03:49:06 charon: 16[IKE] authentication of '100.100.100.100' with pre-shared key successful
        Oct 24 03:49:06 charon: 16[IKE] authentication of '100.100.100.100' with pre-shared key successful
        Oct 24 03:49:06 charon: 16[CFG] constraint check failed: identity '192.168.0.16' required
        Oct 24 03:49:06 charon: 16[CFG] constraint check failed: identity '192.168.0.16' required
        Oct 24 03:49:06 charon: 16[CFG] selected peer config 'asus-to-remote' unacceptable: constraint checking failed
        Oct 24 03:49:06 charon: 16[CFG] selected peer config 'asus-to-remote' unacceptable: constraint checking failed
        Oct 24 03:49:06 charon: 16[CFG] no alternative config found
        Oct 24 03:49:06 charon: 16[CFG] no alternative config found
        Oct 24 03:49:06 charon: 16[ENC] generating INFORMATIONAL request 2 [ N(AUTH_FAILED) ]
        Oct 24 03:49:06 charon: 16[ENC] generating INFORMATIONAL request 2 [ N(AUTH_FAILED) ]

The error is explicitly saying what the issue is.  This is our current configuration:

        conn asus-to-remote
                left=192.168.0.16
                leftid=100.100.100.100
                right=192.168.0.6
                rightid=192.168.0.16

Notice how the ID's are wrong.  Both leftid and rightid.  The new config:

        conn asus-to-remote
                left=192.168.0.16
                leftid=123.123.123.123
                right=192.168.0.6
                rightid=100.100.100.100


MESSAGE:

The following message indicates a mismatch in the IKE encryption algorithm.

        Oct 24 04:00:51 charon: 11[CFG] selected proposal: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
        Oct 24 04:00:51 charon: 11[CFG] selected proposal: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
        Oct 24 04:00:51 charon: 13[NET] received packet: from 192.168.0.6[4500] to 192.168.0.16[4500] (76 bytes)
        Oct 24 04:00:51 charon: 13[NET] received packet: from 192.168.0.6[4500] to 192.168.0.16[4500] (76 bytes)
        Oct 24 04:00:51 charon: 13[ENC] parsed IKE_AUTH response 1 [ N(MS_STATUS(4320)) ]
        Oct 24 04:00:51 charon: 13[ENC] parsed IKE_AUTH response 1 [ N(MS_STATUS(4320)) ]
        Oct 24 04:00:51 charon: 13[IKE] received MS_NOTIFY_STATUS notify error
        Oct 24 04:00:51 charon: 13[IKE] received MS_NOTIFY_STATUS notify error
        Oct 24 04:00:51 charon: 11[IKE] local host is behind NAT, sending keep alives
        Oct 24 04:00:51 charon: 11[IKE] local host is behind NAT, sending keep alives
        Oct 24 04:00:51 charon: 11[IKE] remote host is behind NAT
        Oct 24 04:00:51 charon: 11[IKE] remote host is behind NAT
    

In this case, adjust the encryptions used on the ike= line to the following from the earlier one above:

ike=aes256-sha2_256-modp1024,aes256-sha1-modp1024
esp=aes256gcm16,aes256-sha1


MESSAGE:

(NOTE: Not 100% certain this had the desired effect.  Please see second solution below.) This message below:

        Oct 24 04:40:52 charon: 16[KNL] error installing route with policy 10.0.0.0/24 === 10.10.0.0/24 out
        Oct 24 04:40:52 charon: 16[KNL] error installing route with policy 10.0.0.0/24 === 10.10.0.0/24 out
        Oct 24 04:40:52 charon: 16[IKE] unable to install IPsec policies (SPD) in kernel
        Oct 24 04:40:52 charon: 16[IKE] unable to install IPsec policies (SPD) in kernel

Particulaly, the one that mensions "unable to install IPsec policies (SPD) in kernel" can be resolved by setting the following kernel property to enable loose reverse path filtering:

        https://access.redhat.com/solutions/53031
    
        admin@ASUS-MERLIN-INTERNET:/tmp/mnt/sda/entware/etc# echo 2 > /proc/sys/net/ipv4/conf/all/rp_filter
        admin@ASUS-MERLIN-INTERNET:/tmp/mnt/sda/entware/etc# cat /proc/sys/net/ipv4/conf/all/rp_filter
        2
        admin@ASUS-MERLIN-INTERNET:/tmp/mnt/sda/entware/etc#

The default value on these routers is set to -1, which has no definition:

        admin@ASUS-MERLIN-INTERNET:/tmp/mnt/sda/entware/etc# cat /proc/sys/net/ipv4/conf/all/rp_filter
        -1
        admin@ASUS-MERLIN-INTERNET:/tmp/mnt/sda/entware/etc#

Value of 0, which is used on DD-WRT routers, disables this.  The value on OpenWRT routers is:

root@OWRT01:~# cat /proc/sys/net/ipv4/conf/all/rp_filter
0
root@OWRT01:~#

MESSAGE:

For the following message:

        Oct 24 18:00:21 charon: 11[ENC] payload type NOTIFY was not encrypted
        Oct 24 18:00:21 charon: 11[ENC] payload type NOTIFY was not encrypted
        Oct 24 18:00:21 charon: 11[ENC] could not decrypt payloads
        Oct 24 18:00:21 charon: 11[ENC] could not decrypt payloads

Not clear what the solution was here.  This could have been one of the resultant errors of earlier issues above, including missing algorithm modules in the kernel or other missing kernel modules.  Please the rest of the solutions in this post.

MESSAGE:

This may show up as well:
    
        Sat Oct 24 17:26:57 2020 authpriv.info : 08[NET] sending packet: from 192.168.0.6[500] to 192.168.0.16[500] (1232 bytes)
        Sat Oct 24 17:26:57 2020 daemon.info : 08[NET] sending packet: from 192.168.0.6[500] to 192.168.0.16[500] (1232 bytes)
        Sat Oct 24 17:26:57 2020 authpriv.info : 13[NET] error writing to socket: Network unreachable
        Sat Oct 24 17:26:57 2020 daemon.info : 13[NET] error writing to socket: Network unreachable
        Sat Oct 24 17:26:57 2020 authpriv.info : 08[IKE] retransmit 2 of request with message ID 0
        Sat Oct 24 17:26:57 2020 daemon.info : 08[IKE] retransmit 2 of request with message ID 0

The reason why this was the issue is because the IP was not changed to the router's IP to where the Strongswan config was ported too.  Config had 192.168.0.16, an external router however this router's IP was 192.168.0.12.  Changing:
    
        conn asus-any-to-remote
            left=192.168.0.12

            
to
    
        conn asus-any-to-remote
            left=192.168.0.16

            
    fixed the issue.
    

MESSAGE:

Receiving this:

            unable to install IPsec policies (SPD) in kernel

Within:
        
            Sat Oct 24 18:09:36 2020 authpriv.info : 12[KNL] can't install route for 192.168.0.12/32 === 192.168.0.6/32 out, conflicts with IKE traffic
            Sat Oct 24 18:09:36 2020 daemon.info : 12[KNL] can't install route for 192.168.0.12/32 === 192.168.0.6/32 out, conflicts with IKE traffic
            Sat Oct 24 18:09:36 2020 authpriv.info : 12[IKE] unable to install IPsec policies (SPD) in kernel
            Sat Oct 24 18:09:36 2020 daemon.info : 12[IKE] unable to install IPsec policies (SPD) in kernel
            Sat Oct 24 18:09:36 2020 authpriv.info : 12[IKE] failed to establish CHILD_SA, keeping IKE_SA
            Sat Oct 24 18:09:36 2020 daemon.info : 12[IKE] failed to establish CHILD_SA, keeping IKE_SA

To solve this, two actions were taken,.  First one, was to install ipsec-tools:
        
            root@OWRT01:~# opkg install ipsec-tools
            Installing ipsec-tools (0.8.2-9) to root…
            Downloading http://downloads.openwrt.org/releases/19.07.0/packages/arm_cortex-a7_neon-vfpv4/packages/ipsec-tools_0.8.2-9_arm_cortex-a7_neon-vfpv4.ipk
            Configuring ipsec-tools.
            root@OWRT01:~#

        
kernel-libipsec was removed because it is not the preferred option to use:
        
            root@OWRT01:~# opkg remove strongswan-mod-kernel-libipsec
            Removing package strongswan-mod-kernel-libipsec from root…
            root@OWRT01:~#

MESSAGE:

This error means the negotiated algorithm is not supported by the kernel (received netlink error: Function not implemented (38)):
        
            Sat Oct 24 18:37:28 2020 authpriv.info : 09[CFG] selected proposal: ESP:AES_GCM_16_256/NO_EXT_SEQ
            Sat Oct 24 18:37:28 2020 daemon.info : 09[CFG] selected proposal: ESP:AES_GCM_16_256/NO_EXT_SEQ
            Sat Oct 24 18:37:28 2020 authpriv.info : 09[KNL] received netlink error: Function not implemented (38)
            Sat Oct 24 18:37:28 2020 daemon.info : 09[KNL] received netlink error: Function not implemented (38)
            Sat Oct 24 18:37:28 2020 authpriv.info : 09[KNL] unable to add SAD entry with SPI c07d631d (FAILED)
            Sat Oct 24 18:37:28 2020 daemon.info : 09[KNL] unable to add SAD entry with SPI c07d631d (FAILED)
            Sat Oct 24 18:37:28 2020 authpriv.info : 09[KNL] received netlink error: Function not implemented (38)
            Sat Oct 24 18:37:28 2020 daemon.info : 09[KNL] received netlink error: Function not implemented (38)
            Sat Oct 24 18:37:28 2020 authpriv.info : 09[KNL] unable to add SAD entry with SPI c0cefebb (FAILED)
            Sat Oct 24 18:37:28 2020 daemon.info : 09[KNL] unable to add SAD entry with SPI c0cefebb (FAILED)
            Sat Oct 24 18:37:28 2020 authpriv.info : 09[IKE] unable to install inbound and outbound IPsec SA (SAD) in kernel
            Sat Oct 24 18:37:28 2020 daemon.info : 09[IKE] unable to install inbound and outbound IPsec SA (SAD) in kernel
            Sat Oct 24 18:37:28 2020 authpriv.info : 09[IKE] failed to establish CHILD_SA, keeping IKE_SA
            Sat Oct 24 18:37:28 2020 daemon.info : 09[IKE] failed to establish CHILD_SA, keeping IKE_SA

Following this post:

https://wiki.strongswan.org/issues/2121

Install the missing algorithm.  In our case, on OpenWRT, use opkg list | grep <ALGO> to search for then install the missing algorithm.  In our case, GCM was not installed as a kernel module:
        
            root@OWRT01:~# opkg list | grep -Ei gcm
            kmod-crypto-gcm – 4.14.180-1 – GCM/GMAC CryptoAPI module
            kmod-crypto-gcm – 4.14.180-1 – GCM/GMAC CryptoAPI module
            strongswan-mod-gcm – 5.8.2-2 – StrongSwan GCM AEAD wrapper crypto plugin
            strongswan-mod-gcm – 5.8.2-2 – StrongSwan GCM AEAD wrapper crypto plugin
            root@OWRT01:~# opkg list-installed|grep gcm
            strongswan-mod-gcm – 5.8.2-2
            root@OWRT01:~# opkg install kmod-crypto-gcm
            Installing kmod-crypto-gcm (4.14.180-1) to root…
            Downloading htt p://downloads.openwrt.org/releases/19.07.3/targets/brcm2708/bcm2709/kmods/4.14.180-1-2911c85b0fe34f5899879f41e832a894/kmod-crypto-gcm_4.14.180-1_arm_cortex-a7_neon-vfpv4.ipk
            Installing kmod-crypto-seqiv (4.14.180-1) to root…
            Downloading htt p://downloads.openwrt.org/releases/19.07.3/targets/brcm2708/bcm2709/kmods/4.14.180-1-2911c85b0fe34f5899879f41e832a894/kmod-crypto-seqiv_4.14.180-1_arm_cortex-a7_neon-vfpv4.ipk
            Installing kmod-crypto-ctr (4.14.180-1) to root…
            Downloading htt p://downloads.openwrt.org/releases/19.07.3/targets/brcm2708/bcm2709/kmods/4.14.180-1-2911c85b0fe34f5899879f41e832a894/kmod-crypto-ctr_4.14.180-1_arm_cortex-a7_neon-vfpv4.ipk
            Installing kmod-crypto-gf128 (4.14.180-1) to root…
            Downloading htt p://downloads.openwrt.org/releases/19.07.3/targets/brcm2708/bcm2709/kmods/4.14.180-1-2911c85b0fe34f5899879f41e832a894/kmod-crypto-gf128_4.14.180-1_arm_cortex-a7_neon-vfpv4.ipk
            Installing kmod-crypto-ghash (4.14.180-1) to root…
            Downloading htt p://downloads.openwrt.org/releases/19.07.3/targets/brcm2708/bcm2709/kmods/4.14.180-1-2911c85b0fe34f5899879f41e832a894/kmod-crypto-ghash_4.14.180-1_arm_cortex-a7_neon-vfpv4.ipk
            Configuring kmod-crypto-gf128.
            Configuring kmod-crypto-seqiv.
            Configuring kmod-crypto-ctr.
            Configuring kmod-crypto-ghash.
            Configuring kmod-crypto-gcm.
            root@OWRT01:~#


MESSAGE (Not fully verified):

After a connection is established, trouble with routing ensues:

            Sat Oct 24 23:46:12 2020 authpriv.info : 15[ENC] parsed CREATE_CHILD_SA request 28 [ SA No TSi TSr ]
            Sat Oct 24 23:46:12 2020 daemon.info : 15[ENC] parsed CREATE_CHILD_SA request 28 [ SA No TSi TSr ]
            Sat Oct 24 23:46:12 2020 authpriv.info : 15[IKE] traffic selectors 192.168.0.0/24 === 10.10.0.0/16 unacceptable
            Sat Oct 24 23:46:12 2020 daemon.info : 15[IKE] traffic selectors 192.168.0.0/24 === 10.10.0.0/16 unacceptable
            Sat Oct 24 23:46:12 2020 authpriv.info : 15[IKE] failed to establish CHILD_SA, keeping IKE_SA
            Sat Oct 24 23:46:12 2020 daemon.info : 15[IKE] failed to establish CHILD_SA, keeping IKE_SA
            Sat Oct 24 23:46:12 2020 authpriv.info : 15[ENC] generating CREATE_CHILD_SA response 28 [ N(TS_UNACCEPT) ]
            Sat Oct 24 23:46:12 2020 daemon.info : 15[ENC] generating CREATE_CHILD_SA response 28 [ N(TS_UNACCEPT) ]

This message disappears when the following configuration item is added:

leftsourceip=%config

As follows:

            conn remote-to-asus
                    left=192.168.0.6
                    leftid=100.100.100.100
                    leftfirewall=yes
                    leftsourceip=%config
                    right=192.168.0.12
                    rightid=123.123.123.123
                    rightfirewall=yes

                    # leftsubnet=0.0.0.0/0
                    leftsubnet=192.168.0.0/24,10.0.0.0/24,10.1.0.0/24,10.2.0.0/24,10.3.0.0/24       # Home LAB – Local
                    # rightsubnet=0.0.0.0/0
                    rightsubnet=10.10.0.0/24,10.10.10.0/24,10.10.20.0/24,10.10.30.0/24    # Remote network subnet defined in public cloud

However, that will not necessarily work because, if you notice, 10.10.0.0/16 ends in /16.  Not /24.  Which is likely the big issue here.

        
MESSAGE:

        Following the above solution, the following message is now printed:
        
            Sat Oct 24 23:47:46 2020 authpriv.info : 14[IKE] IKE_SA remote-to-asus[7] established between 192.168.0.12[123.123.123.123]…192.168.0.6[100.100.100.100]
            Sat Oct 24 23:47:46 2020 daemon.info : 14[IKE] IKE_SA remote-to-asus[7] established between 192.168.0.12[123.123.123.123]…192.168.0.6[100.100.100.100]
            Sat Oct 24 23:47:46 2020 authpriv.info : 14[IKE] scheduling reauthentication in 28544s
            Sat Oct 24 23:47:46 2020 daemon.info : 14[IKE] scheduling reauthentication in 28544s
            Sat Oct 24 23:47:46 2020 authpriv.info : 14[IKE] maximum IKE_SA lifetime 28724s
            Sat Oct 24 23:47:46 2020 daemon.info : 14[IKE] maximum IKE_SA lifetime 28724s
            Sat Oct 24 23:47:46 2020 authpriv.info : 14[IKE] expected a virtual IP request, sending FAILED_CP_REQUIRED
            Sat Oct 24 23:47:46 2020 daemon.info : 14[IKE] expected a virtual IP request, sending FAILED_CP_REQUIRED
            Sat Oct 24 23:47:46 2020 authpriv.info : 14[IKE] configuration payload negotiation failed, no CHILD_SA built
            Sat Oct 24 23:47:46 2020 daemon.info : 14[IKE] configuration payload negotiation failed, no CHILD_SA built
            Sat Oct 24 23:47:46 2020 authpriv.info : 14[IKE] failed to establish CHILD_SA, keeping IKE_SA
            Sat Oct 24 23:47:46 2020 daemon.info : 14[IKE] failed to establish CHILD_SA, keeping IKE_SA
            Sat Oct 24 23:47:46 2020 authpriv.info : 14[ENC] generating IKE_AUTH response 1 [ IDr AUTH N(AUTH_LFT) N(FAIL_CP_REQ) ]
            Sat Oct 24 23:47:46 2020 daemon.info : 14[ENC] generating IKE_AUTH response 1 [ IDr AUTH N(AUTH_LFT) N(FAIL_CP_REQ) ]

Unfortunately, when lefrsourceip=%onfig is used, the above is printed.  Simply remove this option.


MESSAGE:

Returning to the earlier issue, the following is printed again after reverting the previous MESSAGE: change:

Sat Oct 24 23:46:12 2020 authpriv.info : 15[IKE] traffic selectors 192.168.0.0/24 === 10.10.0.0/16 unacceptable

The log message appears in a block like this:
        
            Sat Oct 24 23:46:12 2020 authpriv.info : 15[ENC] parsed CREATE_CHILD_SA request 28 [ SA No TSi TSr ]
            Sat Oct 24 23:46:12 2020 daemon.info : 15[ENC] parsed CREATE_CHILD_SA request 28 [ SA No TSi TSr ]
            Sat Oct 24 23:46:12 2020 authpriv.info : 15[IKE] traffic selectors 192.168.0.0/24 === 10.10.0.0/16 unacceptable
            Sat Oct 24 23:46:12 2020 daemon.info : 15[IKE] traffic selectors 192.168.0.0/24 === 10.10.0.0/16 unacceptable
            Sat Oct 24 23:46:12 2020 authpriv.info : 15[IKE] failed to establish CHILD_SA, keeping IKE_SA
            Sat Oct 24 23:46:12 2020 daemon.info : 15[IKE] failed to establish CHILD_SA, keeping IKE_SA
            Sat Oct 24 23:46:12 2020 authpriv.info : 15[ENC] generating CREATE_CHILD_SA response 28 [ N(TS_UNACCEPT) ]
            Sat Oct 24 23:46:12 2020 daemon.info : 15[ENC] generating CREATE_CHILD_SA response 28 [ N(TS_UNACCEPT) ]

        
Some of the suggestions include adding in a leftsourceip.  This did not work for us.  

https://wiki.strongswan.org/projects/strongswan/wiki/ConnSection

Reviewing the documentation, and some oneline recommendations, appears these are the settings that could solve it in this case:

leftsourceip = %config4 | %config6 | <ip address>

                    The internal source IP to use in a tunnel, also known as virtual IP.
                    If the value is one of the synonyms %config, %cfg, %modeconfig or %modecfg, an address (from
                    the tunnel address family) is requested from the peer.
                    Since 5.0.1 a comma-separated list is accepted to request multiple addresses, and with %config4 and
                    %config6 an address of the given address family will be requested explicitly.
                    If an IP address is configured, it will be requested from the responder, which is free to respond with a
                    different address.

rightsourceip = %config | <network>/<netmask> | <from>-<to> | %poolname

                    The internal source IP to use in a tunnel for the remote peer. If the value is config on the responder
                    side, the initiator must propose an address which is then echoed back. Also supported are address pools
                    expressed as <network>/<netmask> and <from>-<to> (since 5.2.2) or the use of an external IP address pool
                    using %poolname where poolname is the name of the IP address pool used for the lookup (see virtual IP for details).
                    Since 5.0.1 a comma-separated list of IP addresses / pools is accepted, for instance, to define pools of
                    different address families.

However, in this situation, that's not the case.  Looking closely, leftsubnet= and rightsubnet= are reversed for the block and left= and right= side definitions.  They are:
        
            conn remote-to-asus
                left=192.168.0.6
                leftid=100.100.100.100
                leftfirewall=yes
                right=192.168.0.12
                rightid=123.123.123.123
                rightfirewall=yes

                # leftsubnet=0.0.0.0/0
                leftsubnet=192.168.0.0/24,10.0.0.0/24,10.1.0.0/24,10.2.0.0/24,10.3.0.0/24       # Home LAB – Local
                # rightsubnet=0.0.0.0/0
                rightsubnet=10.10.0.0/16,10.10.0.0/24,10.10.10.0/24,10.10.20.0/24,10.10.30.0/24    # Remote network subnet defined in public cloud

Should be as follows, including the entire Azure VPN Address space:

conn remote-to-asus
                left=192.168.0.6
                leftid=100.100.100.100
                leftfirewall=yes
                right=192.168.0.12
                rightid=123.123.123.123
                rightfirewall=yes

                # leftsubnet=0.0.0.0/0
                leftsubnet=10.10.0.0/24,10.10.10.0/24,10.10.20.0/24,10.10.30.0/24    # Remote network subnet defined in public cloud
                # rightsubnet=0.0.0.0/0
                rightsubnet=192.168.0.0/24,10.0.0.0/24,10.1.0.0/24,10.2.0.0/24,10.3.0.0/24       # Home LAB – Local

 

MESSAGE: 

No connectivity to Azure VPN GW.  Cannot ping.  Connection not INSTALLED.  In this case the issue was with another instance of StrongSwan that was running on the main router.  It was taking traffic from the Raspberry Pi 2 StrongSwan implementation instead of forwarding the packets over to Azure VPN GW.  Stop the StrongSwan on the INTERNET facing router.

root@DD-WRT-INTERNET-ASUS:~# ps|grep ipsec
2510 root     /opt/lib/ipsec/starter –daemon charon
2511 root     /opt/lib/ipsec/charon –use-syslog
9324 root     grep ipsec
root@DD-WRT-INTERNET-ASUS:~#

        Even though forwarding is enabled from the WAN back to the on-prem resources, apparently on the way back, the packets were captured by this second StrongSwan GW.

MESSAGE:

Pinging gateways works from the GW's or Azure VM's but there is no route (or no OSPF route) for the remote VLAN's.

[root@azure-r01wn01 ~]# ping 192.168.0.65
PING 192.168.0.65 (192.168.0.65) 56(84) bytes of data.
^C
— 192.168.0.65 ping statistics —
8 packets transmitted, 0 received, 100% packet loss, time 6999ms

[root@azure-r01wn01 ~]# ping 192.168.0.12
PING 192.168.0.12 (192.168.0.12) 56(84) bytes of data.
64 bytes from 192.168.0.12: icmp_seq=1 ttl=64 time=44.7 ms
^C
— 192.168.0.12 ping statistics —
2 packets transmitted, 1 received, 50% packet loss, time 1001ms
rtt min/avg/max/mdev = 44.797/44.797/44.797/0.000 ms
[root@azure-r01wn01 ~]#

Pinging from on-prem to remote:
        
                root@OWRT01:~# ping 10.10.10.4
                PING 10.10.10.4 (10.10.10.4): 56 data bytes
                64 bytes from 10.10.10.4: seq=0 ttl=64 time=50.569 ms
                ^C
                — 10.10.10.4 ping statistics —
                1 packets transmitted, 1 packets received, 0% packet loss
                round-trip min/avg/max = 50.569/50.569/50.569 ms
                root@OWRT01:~#

        From other machines on the local VLAN's, it doesn't work:
        
                ? cm-r01nn01.mws.mds.xyz ? tom@mds.xyz ? ~ ? ping 10.10.10.4
                PING 10.10.10.4 (10.10.10.4) 56(84) bytes of data.
                ^C
                — 10.10.10.4 ping statistics —
                3 packets transmitted, 0 received, 100% packet loss, time 2000ms

                 ? cm-r01nn01.mws.mds.xyz ? tom@mds.xyz ? ~ ? 

        Running a tcpdump shows that the packets arrive at the on-prem GW but don't go anywhere beyond that, indicating local routing issue:
        
                root@OWRT01:~# tcpdump -n | grep -Ei "192.168.0.65"
                tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
                listening on br-lan, link-type EN10MB (Ethernet), capture size 262144 bytes
                11:46:14.813563 IP 10.10.10.4 > 192.168.0.65: ICMP echo request, id 1328, seq 1, length 64
                11:46:14.813838 IP 10.10.10.4 > 192.168.0.65: ICMP echo request, id 1328, seq 1, length 64
                11:46:14.814402 ARP, Request who-has 192.168.0.1 tell 192.168.0.65, length 46
                11:46:15.813730 IP 10.10.10.4 > 192.168.0.65: ICMP echo request, id 1328, seq 2, length 64
                11:46:15.814006 IP 10.10.10.4 > 192.168.0.65: ICMP echo request, id 1328, seq 2, length 64
                11:46:21.812863 IP 10.10.10.4 > 192.168.0.65: ICMP echo request, id 1328, seq 8, length 64
                11:46:21.813127 IP 10.10.10.4 > 192.168.0.65: ICMP echo request, id 1328, seq 8, length 64
                ^C3549 packets captured
                3641 packets received by filter
                0 packets dropped by kernel
                1 packet dropped by interface

                root@OWRT01:~#

        Please see using VTI interfaces above to fully resolve this issue.

        
MESSAGE:

Exporting routes to OSPF from XFRM. IPsec routes are installed in table 220, whereas OSPF installs routes in table 254:

                root@OWRT01:~# ip route list table 220
                10.10.0.0/24 via 192.168.0.6 dev br-lan proto static src 192.168.0.12
                10.10.10.0/24 via 192.168.0.6 dev br-lan proto static src 192.168.0.12
                10.10.20.0/24 via 192.168.0.6 dev br-lan proto static src 192.168.0.12
                10.10.30.0/24 via 192.168.0.6 dev br-lan proto static src 192.168.0.12
                100.100.100.100 via 192.168.0.1 dev br-lan proto static src 192.168.0.12
                192.168.0.6 via 192.168.0.6 dev br-lan proto static src 192.168.0.12
                root@OWRT01:~#
                root@OWRT01:~#
                root@OWRT01:~# ip route list table 254
                default via 192.168.0.1 dev br-lan proto static
                10.0.0.0/24 via 192.168.0.1 dev br-lan proto zebra metric 20
                10.1.0.0/24 via 192.168.0.1 dev br-lan proto zebra metric 20
                10.1.1.0/24 proto zebra metric 20
                        nexthop via 192.168.0.6 dev br-lan weight 1
                        nexthop via 192.168.0.16 dev br-lan weight 1
                10.2.0.0/24 via 192.168.0.1 dev br-lan proto zebra metric 20
                10.3.0.0/24 via 192.168.0.1 dev br-lan proto zebra metric 20
                123.123.123.321/27 via 192.168.0.6 dev br-lan proto zebra metric 20
                192.168.0.0/24 dev br-lan proto kernel scope link src 192.168.0.12
                192.168.45.0/24 via 192.168.0.6 dev br-lan proto zebra metric 20
                192.168.75.0/24 via 192.168.0.6 dev br-lan proto zebra metric 20
                root@OWRT01:~#

                root@OWRT01:~# ip xfrm state
                src 192.168.0.12 dst 192.168.0.6
                        proto esp spi 0x7cceb8b6 reqid 1 mode tunnel
                        replay-window 0 flag af-unspec
                        aead rfc4106(gcm(aes)) 0xbd1c9688faf344359551807b3bcf546d994085f12c0c37d598f3a1729dca4f16b14a7c9e 128
                        encap type espinudp sport 4500 dport 4500 addr 0.0.0.0
                        anti-replay context: seq 0x0, oseq 0x6, bitmap 0x00000000
                src 192.168.0.6 dst 192.168.0.12
                        proto esp spi 0xc006fae8 reqid 1 mode tunnel
                        replay-window 32 flag af-unspec
                        aead rfc4106(gcm(aes)) 0xf87175be8cfc2d1a9f11cd7334700f643bb62100631c4d9628a8a2f6bb2216dc854d3c63 128
                        encap type espinudp sport 4500 dport 4500 addr 0.0.0.0
                        anti-replay context: seq 0x320, oseq 0x0, bitmap 0xffffffff
                root@OWRT01:~#

        This section is not yet fully tested using XFRM on OpenWRT.  (https://forum.openwrt.org/t/creating-xfrm-interfaces-does-anyone-know-how-to-create-the-xfrm-interfaces/77674)
        

MESSAGE:

Cannot ping remote VLAN's from on-prem VLAN's.  

To resolve this issue, route based VPN's will be used.  To do this, create a VTI tunnel.  XFRM is preferred however will visit this option in another section.  First, set kernel parameters:

            sysctl -w net.ipv4.conf.vti1.rp_filter=0
            sysctl -w net.ipv4.conf.vti1.disable_policy=1

    
        Create the tunnel (Notice the IP used will be 192.168.0.13 which is different from the OpenWRT Router IP 192.168.0.12.  Reason for this is to avoid conflict with the router IP. ).
        
            ip tunnel add vti0 local 192.168.0.13 remote 100.100.100.100 mode vti key 42
            ip link set vti0 up
            ip route add 10.10.0.0/24 dev vti0
            ip route add 10.10.10.0/24 dev vti0
            ip route add 10.10.20.0/24 dev vti0
            ip route add 10.10.30.0/24 dev vti0

            
        Add the above lines to Luci -> System -> Startup.  Alternately, define VTI interfaces in /etc/config/network.  Next, add these tags to the default configuration of the ipsec.conf config above:
        
                mark=42
                mark_in=42
                mark_out=42

        
        Save and restart ipsec and OSPFD. 


MESSAGE:

Following messages (Nof fully verified):

        Sun Oct 25 22:48:58 2020 authpriv.info : 06[NET] received unencrypted informational: from 192.168.0.6[500] to 192.168.0.12[500]
        Sun Oct 25 22:48:58 2020 daemon.info : 06[NET] received unencrypted informational: from 192.168.0.6[500] to 192.168.0.12[500]
        Sun Oct 25 22:48:58 2020 authpriv.info : 06[ENC] payload type NOTIFY was not encrypted
        Sun Oct 25 22:48:58 2020 daemon.info : 06[ENC] payload type NOTIFY was not encrypted
        Sun Oct 25 22:48:58 2020 authpriv.info : 06[ENC] could not decrypt payloads
        Sun Oct 25 22:48:58 2020 daemon.info : 06[ENC] could not decrypt payloads
        Sun Oct 25 22:48:58 2020 authpriv.info : 06[IKE] INFORMATIONAL request with message ID 0 processing failed
        Sun Oct 25 22:48:58 2020 daemon.info : 06[IKE] INFORMATIONAL request with message ID 0 processing failed
        Sun Oct 25 22:49:01 2020 authpriv.info : 08[IKE] sending keep alive to 192.168.0.6[500]
        Sun Oct 25 22:49:01 2020 daemon.info : 08[IKE] sending keep alive to 192.168.0.6[500]
        Sun Oct 25 22:49:01 2020 authpriv.info : 10[IKE] sending keep alive to 192.168.0.6[1176]
        Sun Oct 25 22:49:01 2020 daemon.info : 10[IKE] sending keep alive to 192.168.0.6[1176]
        Sun Oct 25 22:49:02 2020 authpriv.info : 07[JOB] deleting half open IKE_SA with 192.168.0.6 after timeout
        Sun Oct 25 22:49:02 2020 daemon.info : 07[JOB] deleting half open IKE_SA with 192.168.0.6 after timeout

        
    Resolved by these DD-WRT iptable rules (https://wiki.strongswan.org/issues/1100):
    
        # Allow IPSec packets through.
        iptables -t nat -I POSTROUTING -m policy –pol ipsec –dir out -j ACCEPT

        # IKE negotiations
        iptables -A INPUT  -p udp –sport 500 –dport 500 -j ACCEPT
        iptables -A OUTPUT -p udp –sport 500 –dport 500 -j ACCEPT
        iptables -A INPUT  -p udp –sport 4500 –dport 4500 -j ACCEPT
        iptables -A OUTPUT -p udp –sport 4500 –dport 4500 -j ACCEPT
        # ESP encrypton and authentication
        iptables -A INPUT  -p 50 -j ACCEPT
        iptables -A OUTPUT -p 50 -j ACCEPT
        # AH authentication header
        iptables -A INPUT  -p 51 -j ACCEPT
        iptables -A OUTPUT -p 51 -j ACCEPT

        
    Now the connection is automagically established on ipsec restart without having to wait for a ping from the remote side for connectivity to be established:
    
            root@OWRT01:~# ipsec status
            Routed Connections:
                azure-s2s{4}:  ROUTED, TUNNEL, reqid 3
                azure-s2s{4}:   192.168.0.12/32 === 100.100.100.100/32
            asus-any-to-remote{3}:  ROUTED, TUNNEL, reqid 2
            asus-any-to-remote{3}:   192.168.0.12/32 === 192.168.0.6/32
            asus-to-remote{2}:  ROUTED, TUNNEL, reqid 2
            asus-to-remote{2}:   192.168.0.12/32 === 192.168.0.6/32
            remote-to-asus{1}:  ROUTED, TUNNEL, reqid 1
            remote-to-asus{1}:   10.0.0.0/24 10.1.0.0/24 10.2.0.0/24 10.3.0.0/24 192.168.0.0/24 === 10.10.0.0/24 10.10.10.0/24 10.10.20.0/24 10.10.30.0/24
            Security Associations (1 up, 0 connecting):
            remote-to-asus[1]: ESTABLISHED 2 minutes ago, 192.168.0.12[123.123.123.123]…192.168.0.6[100.100.100.100]
            remote-to-asus{5}:  INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: cc6ab250_i c7ee3326_o
            remote-to-asus{5}:   10.0.0.0/24 10.1.0.0/24 10.2.0.0/24 10.3.0.0/24 192.168.0.0/24 === 10.10.0.0/24 10.10.10.0/24 10.10.20.0/24 10.10.30.0/24
            root@OWRT01:~#

    However, you will need to wait a few minutes for the tunnel to be fully installed. 

MESSAGE

root@OWRT01:~# logread -l 100 -f

Mon Sep  6 19:24:23 2021 authpriv.info : 00[CFG] line 5: missing ' : ' separator
Mon Sep  6 19:24:23 2021 daemon.info : 00[CFG] line 5: missing ' : ' separator

The config file became corrupted causing the connection to Azure VPN GW to fail. There were special binary characters in the /etc/ipsec.secrets file:

root@OWRT01:~# cat /etc/ipsec.secrets
# /etc/ipsec.secrets – strongSwan IPsec secrets file
123.123.123.123 100.100.100.100 : PSK "PASS"
192.168.0.6 192.168.0.16 : PSK "PASS"
192.168.0.16 192.168.0.6 : PSK "PASS"
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

Remove the special characters from the file and restart ipsec.  Not sure how these characters are added to that file.

MESSAGE

daemon.warn dnsmasq[416]: Maximum number of concurrent DNS queries reached (max: 150)

 

Set the concurrent queries in Luci to something greater then 150.  DHCP and DNS -> Advanced Settings -> 

Also set the DNS Query cache in Luci to something greater then 150.  DHCP and DNS -> Advanced Settings -> 

MESSAGE

Cannot ping the Azure VLAN though an established connection exists in ipsec.  You also see these messages in the log files:

Sep  6 22:31:52 DD-WRT-INTERNET-ASUS kern.warn kernel: DROP IN=br0 OUT= MAC=ff:ff:ff:ff:ff:ff:2c:fd:b1:7d:52:c3:08:00 SRC=0.0.0.0 DST=255.255.255.255 LEN=88 TOS=0x00 PREC=0x00 TTL=255 ID=623 PROTO=139

C:\Windows\system32>ping 10.10.10.4 -t

Pinging 10.10.10.4 with 32 bytes of data:
Request timed out.

The first message is more of a red herring but it is still important for DHCP and DNS resolution.  Ensure you add the following rule:

iptables -A INPUT -s 0.0.0.0 -d 255.255.255.255 -j ACCEPT

Second message is a real issue.  The issue can be traced to the firewall simply by restarting the firewall on that router.  The ping then succeeds. However, some of the accompanying messages include:

udp port 500 unreachable
udp port 4500 unreachable

IP 1.2.3.4 > 5.6.7.8: ICMP 1.2.3.4 udp port 4500 unreachable, length 440

To resolve the unreachable messages, add the following:

iptables -A INPUT -j ACCEPT -p icmp -m multiport –dports 500,4500 

Once you add those rules, the next message that will be printed will be:

Reply from 192.168.0.12: TTL expired in transit.

Alongside:

Mon Sep  6 23:18:25 2021 authpriv.info : 08[IKE] failed to establish CHILD_SA, keeping IKE_SA

traffic selectors 192.168.0.0/24 === 10.10.0.0/16 unacceptable

The reason for that is that OSPF isn't grabbing the proper routes, however the other routers were. 

DD-WRT-INTERNET-ASUS# sh ip ospf route
============ OSPF network routing table ============
N    192.168.0.0/24        [10] area: 0.0.0.0
                           directly attached to br0

============ OSPF router routing table =============

============ OSPF external routing table ===========

DD-WRT-INTERNET-ASUS#

Neither was OpenWRT:

root@OWRT01:~# vtysh

Hello, this is Quagga (version 1.1.1).
Copyright 1996-2005 Kunihiro Ishiguro, et al.

OWRT01# sh ip ospf route
============ OSPF network routing table ============
N    10.0.0.0/24           [11] area: 0.0.0.0
                           via 192.168.0.1, br-lan
N    10.1.0.0/24           [11] area: 0.0.0.0
                           via 192.168.0.1, br-lan
N    10.2.0.0/24           [11] area: 0.0.0.0
                           via 192.168.0.1, br-lan
N    10.3.0.0/24           [11] area: 0.0.0.0
                           via 192.168.0.1, br-lan
N    192.168.0.0/24        [10] area: 0.0.0.0
                           directly attached to br-lan

============ OSPF router routing table =============

============ OSPF external routing table ===========

OWRT01#

Meaning tunnel is not fully established. Local VLAN's aren't working either.  One of these rules was blocking it.  Appears the ones in red were, the one in green wasn't:

# iptables -P FORWARD logdrop
# iptables -P INPUT logdrop
iptables -P OUT logdrop
# iptables -A INPUT -j logdrop

However, one of the routers still failed to grab routes.  Looking closer into the OSPF logs, this is what is printed:

/jffs/ospf/ospf.log
OSPF MPLS-TE: Abort update TE parameters: no Link Parameters for interface

The correct configuration to use on the main OSPF Asus router is:

!
hostname DD-WRT-INTERNET-ASUS
log file /jffs/ospf/ospf.log
!
! debug ospf ism
! debug ospf nsm
! debug ospf lsa
! debug ospf zebra
! debug ospf nssa
! debug ospf packet all
!
router ospf
  ospf router-id 192.168.0.6
  log-adjacency-changes
  network 192.168.0.0/24 area 0
  redistribute kernel
  redistribute connected
  redistribute static
  default-information originate
!
line vty
!

 

Pages: 1 2 3 4 5 6 7

Leave a Reply

You must be logged in to post a comment.


     
  Copyright © 2003 - 2013 Tom Kacperski (microdevsys.com). All rights reserved.

Creative Commons License
This work is licensed under a Creative Commons Attribution 3.0 Unported License