On 6/19/2020 10:56 PM, Brian Topping wrote:
Sounds like you’re unable to look at traffic on both sides. Unless you’re
looking closely at the logs and know what’s happening, it’s hard to debug. It
also looks as if you’ve rather heavily sanitized the console logs, for instance
the ping destination.
This line concerns me:
Jun 19 19:57:11 14[KNL] error installing route with policy 10.3.0.0/24 ===
10.10.0.0/24 out
If your are coming from or going to 100.100.100.100 and using transport instead
of tunnel, these routes being installed are wrong, which becomes a
configuration issue.
Best way to post is to take the console output verbatim, then replace the first
two octets of every IP address you want to sanitize with unique letters so the
addresses can be distinguished. Easier if you can put the content into
something like pastebin or gist instead of mailing to the list for viewing
purposes.
Sent from my iPhone
On Jun 19, 2020, at 19:28, TomK <tomk...@mdevsys.com> wrote:
Jun 19 19:57:11 14[KNL] error installing route with policy 10.3.0.0/24 ===
10.10.0.0/24 out
Thank you. Attached the logs.
https COLON //www DOT microdevsys DOT com/WordPressFiles/charon.log
https COLON //www DOT microdevsys DOT
com/WordPressFiles/var-log-messages.txt
Config files:
root@DD-WRT:~# cat /opt/etc/ipsec.conf
# ipsec.conf - strongSwan IPsec configuration file
# basic configuration
config setup
# strictcrlpolicy=yes
# uniqueids = no
# Add connections here.
conn REMOTE-VLAN1
authby=secret
auto=start
type=tunnel
keyexchange=ikev2
keylife=3600s
ikelifetime=28800s
rekey=yes
rekeymargin=3m
keyingtries=1
mobike=no
dpdaction=none
lifebytes=102400000
left=100.100.100.100
# IP address of your on-premises gateway
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
# leftnexthop=%defaultroute
right=123.123.123.123
# Remote VPN gateway IP address
rightsubnet=10.10.0.0/24,10.10.1.0/24,10.10.2.0/24,10.10.3.0/24,10.10.4.0/24
# Remote network subnet defined in public cloud
ike=aes256-sha1-modp1024
esp=aes256-sha1
root@DD-WRT:~#
root@DD-WRT:~# cat /opt/etc/strongswan.conf
# strongswan.conf - strongSwan configuration file
#
# Refer to the strongswan.conf(5) manpage for details
#
# Configuration changes should be made in the included files
# Verbosity levels
# -1: Absolutely silent
# 0: Very basic auditing logs, (e.g. SA up/SA down)
# 1: Generic control flow with errors, a good default to see whats going on
# 2: More detailed debugging control flow
# 3: Including RAW data dumps in Hex
# 4: Also include sensitive material in dumps, e.g. keys
charon {
load_modular = yes
plugins {
include strongswan.d/charon/*.conf
}
filelog {
charon {
path = /opt/tmp/charon.log
time_format = %b %e %T
append = no
default = 2 # in case troubleshoot is required
switch this to 2
}
stderr {
ike = 2 # in case troubleshoot is required
switch this to 2
knl = 3 # in case troubleshoot is required
switch this to 3
ike_name = yes
}
}
syslog {
# enable logging to LOG_DAEMON, use defaults
daemon {
}
# minimalistic IKE auditing logging to LOG_AUTHPRIV
auth {
default = 2 # in case troubleshoot is required
switch this to 2
ike = 2 # in case troubleshoot is required
switch this to 2
}
}
}
include strongswan.d/*.conf
root@DD-WRT:~#
root@DD-WRT:~# ipsec statusall
Status of IKE charon daemon (strongSwan 5.8.2, Linux 4.4.190, armv7l):
uptime: 28 seconds, since Jun 19 23:04:51 2020
malloc: sbrk 892928, mmap 0, used 493392, free 399536
worker threads: 6 of 16 idle, 6/0/4/0 working, job queue: 0/0/0/0,
scheduled: 4
loaded plugins: charon test-vectors ldap pkcs11 aes des blowfish rc2
sha2 sha1 md4 md5 random nonce x509 revoca tion
constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem
openssl gcrypt fips-prf gmp gmpdh curve255 19
agent xcbc cmac hmac ctr ccm gcm curl mysql sqlite attr kernel-libipsec
kernel-netlink resolve socket-default
socket-dynamic farp stroke vici smp updown eap-identity eap-md5
eap-mschapv2 eap-radius eap-tls xauth-generic xau
th-eap dhcp whitelist led duplicheck addrblock unity
Listening IP addresses:
100.100.100.100
192.168.0.6
192.168.45.1
192.168.75.1
10.1.1.1
Connections:
AZURE-VLAN1: 100.100.100.100...123.123.123.123 IKEv2
AZURE-VLAN1: local: [100.100.100.100] uses pre-shared key
authentication
AZURE-VLAN1: remote: [123.123.123.123] uses pre-shared key
authentication
AZURE-VLAN1: child: 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 === 10.10.0.0/24 10.10.1.0
/24 10.10.2.0/24 10.10.3.0/24 10.10.4.0/24 TUNNEL
Security Associations (1 up, 0 connecting):
AZURE-VLAN1[1]: ESTABLISHED 27 seconds ago,
100.100.100.100[100.100.100.100]...123.123.123.123[123.123.123.123]
AZURE-VLAN1[1]: IKEv2 SPIs: 5464f1e04af780fd_i* fa01060f92607d17_r,
pre-shared key reauthentication in 7 hours
AZURE-VLAN1[1]: IKE proposal:
AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
root@DD-WRT:~#
root@DD-WRT:~# opkg list-installed|grep -Ei strongswan
strongswan - 5.8.2-1
strongswan-charon - 5.8.2-1
strongswan-ipsec - 5.8.2-1
strongswan-libtls - 5.8.2-1
strongswan-mod-addrblock - 5.8.2-1
strongswan-mod-aes - 5.8.2-1
strongswan-mod-af-alg - 5.8.2-1
strongswan-mod-agent - 5.8.2-1
strongswan-mod-attr - 5.8.2-1
strongswan-mod-attr-sql - 5.8.2-1
strongswan-mod-blowfish - 5.8.2-1
strongswan-mod-ccm - 5.8.2-1
strongswan-mod-cmac - 5.8.2-1
strongswan-mod-constraints - 5.8.2-1
strongswan-mod-coupling - 5.8.2-1
strongswan-mod-ctr - 5.8.2-1
strongswan-mod-curl - 5.8.2-1
strongswan-mod-curve25519 - 5.8.2-1
strongswan-mod-des - 5.8.2-1
strongswan-mod-dhcp - 5.8.2-1
strongswan-mod-dnskey - 5.8.2-1
strongswan-mod-duplicheck - 5.8.2-1
strongswan-mod-eap-identity - 5.8.2-1
strongswan-mod-eap-md5 - 5.8.2-1
strongswan-mod-eap-mschapv2 - 5.8.2-1
strongswan-mod-eap-radius - 5.8.2-1
strongswan-mod-eap-tls - 5.8.2-1
strongswan-mod-farp - 5.8.2-1
strongswan-mod-fips-prf - 5.8.2-1
strongswan-mod-gcm - 5.8.2-1
strongswan-mod-gcrypt - 5.8.2-1
strongswan-mod-gmp - 5.8.2-1
strongswan-mod-gmpdh - 5.8.2-1
strongswan-mod-ha - 5.8.2-1
strongswan-mod-hmac - 5.8.2-1
strongswan-mod-kernel-libipsec - 5.8.4-1
strongswan-mod-kernel-netlink - 5.8.2-1
strongswan-mod-ldap - 5.8.2-1
strongswan-mod-led - 5.8.2-1
strongswan-mod-load-tester - 5.8.2-1
strongswan-mod-md4 - 5.8.2-1
strongswan-mod-md5 - 5.8.2-1
strongswan-mod-mysql - 5.8.2-1
strongswan-mod-nonce - 5.8.2-1
strongswan-mod-openssl - 5.8.2-1
strongswan-mod-pem - 5.8.2-1
strongswan-mod-pgp - 5.8.2-1
strongswan-mod-pkcs1 - 5.8.2-1
strongswan-mod-pkcs11 - 5.8.2-1
strongswan-mod-pkcs12 - 5.8.2-1
strongswan-mod-pkcs7 - 5.8.2-1
strongswan-mod-pkcs8 - 5.8.2-1
strongswan-mod-pubkey - 5.8.2-1
strongswan-mod-random - 5.8.2-1
strongswan-mod-rc2 - 5.8.2-1
strongswan-mod-resolve - 5.8.2-1
strongswan-mod-revocation - 5.8.2-1
strongswan-mod-sha1 - 5.8.2-1
strongswan-mod-sha2 - 5.8.2-1
strongswan-mod-smp - 5.8.2-1
strongswan-mod-socket-default - 5.8.2-1
strongswan-mod-socket-dynamic - 5.8.2-1
strongswan-mod-sql - 5.8.2-1
strongswan-mod-sqlite - 5.8.2-1
strongswan-mod-sshkey - 5.8.2-1
strongswan-mod-stroke - 5.8.2-1
strongswan-mod-test-vectors - 5.8.2-1
strongswan-mod-unity - 5.8.2-1
strongswan-mod-updown - 5.8.2-1
strongswan-mod-vici - 5.8.2-1
strongswan-mod-whitelist - 5.8.2-1
strongswan-mod-x509 - 5.8.2-1
strongswan-mod-xauth-eap - 5.8.2-1
strongswan-mod-xauth-generic - 5.8.2-1
strongswan-mod-xcbc - 5.8.2-1
strongswan-pki - 5.8.2-1
strongswan-scepclient - 5.8.2-1
strongswan-swanctl - 5.8.2-1
root@DD-WRT:~#
Firewall config. I had lines like this:
iptables -I FORWARD -s 10.10.0.0/24 -d 192.168.0.0/24 -j ACCEPT
iptables -I INPUT -p icmp -s 10.10.0.0/24 -d 192.168.0.0/24 -j ACCEPT
But when I took them out, it made no difference at all. So I effectively
have nothing for StrongSwan in my local F/W configuration at the moment.
100.100.100.100 is my local environment. 123.123.123.123 is a remote
cloud provider, Azure. I'm also running OSPF on the DD-WRT LOCAL
routers so none of my routers are configured as Gateways as typically
would be the case. OSPF handles my local routing. Works like a charm.
ISSUE DESCRIPTION ------------------------------
When I try to ping the remote cloud VM on 10.10.0.4 from my local router
that I'm using for StrongSwan:
root@DD-WRT:~# ping 10.10.0.4
PING 10.10.0.4 (10.10.0.4): 56 data bytes
Nothing happens. There is no activity on the ipsec0 interface at all:
# tcpdump -i ipsec0 -s 0 -n arp or icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ipsec0, link-type RAW (Raw IP), snapshot length 262144 bytes
(EMPTY)
At this point I SSH to the cloud VM via the public IP and initiate a
ping in return to any IP on my LOCAL on-PREM environment VLAN
192.168.0.0/24 and this works fine:
[root@cm-azure-wn03 ~]# ping 192.168.0.154
PING 192.168.0.154 (192.168.0.154) 56(84) bytes of data.
(short pause)
64 bytes from 192.168.0.154: icmp_seq=4 ttl=63 time=46.5 ms
64 bytes from 192.168.0.154: icmp_seq=5 ttl=63 time=48.5 ms
64 bytes from 192.168.0.154: icmp_seq=6 ttl=63 time=46.6 ms
SSH and everything else works great from REMOTE to LOCAL as well.
[root@cm-azure-wn03 ~]# ip route show
default via 10.10.0.1 dev eth0 proto dhcp metric 100
10.10.0.0/24 dev eth0 proto kernel scope link src 10.10.0.4 metric 100
168.63.100.16 via 10.10.0.1 dev eth0 proto dhcp metric 100
169.254.100.254 via 10.10.0.1 dev eth0 proto dhcp metric 100
[root@cm-azure-wn03 ~]#
and sure enough, traffic is registered on the tcpdump running against
the ipsec01 interface when pinging from REMOTE to LOCAL, as expected:
root@DD-WRT:~# tcpdump -i ipsec0 -s 0 -n arp or icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ipsec0, link-type RAW (Raw IP), snapshot length 262144 bytes
23:46:03.793056 IP 10.10.0.4 > 192.168.0.154: ICMP echo request, id
7426, seq 1, length 64
23:46:03.796663 IP 192.168.0.154 > 10.10.0.4: ICMP echo reply, id 7426,
seq 1, length 64
23:46:04.869369 IP 10.10.0.4 > 192.168.0.154: ICMP echo request, id
7426, seq 2, length 64
23:46:04.872168 IP 192.168.0.154 > 10.10.0.4: ICMP echo reply, id 7426,
seq 2, length 64
So from REMOTE to LOCAL it works fine. But now here's where it get's
interesting. I'll go back to the LOCAL terminal whence I started the
first ping and repeat the ping once more:
root@DD-WRT:~# ping 10.10.0.4
PING 10.10.0.4 (10.10.0.4): 56 data bytes
And now I see ICMP echo requests going out and registering on ipsec0.
# tcpdump -i ipsec0 -s 0 -n icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ipsec0, link-type RAW (Raw IP), snapshot length 262144 bytes
23:59:25.566796 IP 100.100.100.100 > 10.10.0.4: ICMP echo request, id
63869, seq 5, length 64
23:59:26.576196 IP 100.100.100.100 > 10.10.0.4: ICMP echo request, id
63869, seq 6, length 64
23:59:27.585537 IP 100.100.100.100 > 10.10.0.4: ICMP echo request, id
63869, seq 7, length 64
23:59:28.598500 IP 100.100.100.100 > 10.10.0.4: ICMP echo request, id
63869, seq 8, length 64
but no reply is coming back. Next, I tried to add some NAT rules:
root@DD-WRT:~# iptables -t nat -I POSTROUTING -s 10.10.0.0/24 -m policy
--dir out --pol ipsec -j ACCEPT
iptables v1.3.7: Couldn't find match `policy'
but no luck.
At this point I'm thinking it could be one of these four items:
1) Azure VPN Gateway is blocking ping from LOCAL to REMOTE. Having
trouble figuring out how to pin point this via their logs or StrongSwan
logs.
2) StrongSwan is misconfigured so pings towards one of the REMOTE VLAN's
is never sent over the StrongSwan VPN Gateway at all. Leaning towards
this since packets aren't even making it into ipsec0 interface to begin
with unless I ping from REMOTE to LOCAL. At that point it appears they
terminate at the ipsec0 interface and go no further, hence suspecting
misconfiguration. But can't prove it yet.
3) I need NAT rules such as the one above.
4) I'm missing kernel modules on DD-WRT. Or a module isn't loaded, when
it should be.
--
Thx,
TK.
