[strongSwan] Site-to-Site VPN - GRE over IPSec - Multicast - Cisco Router to StrongSwan (Centos 7) Issues
Rx Networks - Netops
netops at rxnetworks.com
Thu Jan 21 18:17:09 CET 2021
The ultimate goal is to be able to subscribe to multicast traffic (239.100.100.13) being generated behind the cisco router on the server hosting strongswan. Ideally we would like to also forward this traffic onto the network behind strongswan however we understand that that step in AWS VPCs is not trivial/possible without additional tunnels/configuration. Any help would be appreciated.
We are having an issue setting up site-to-site vpn in our environment. Both the router and the strongswan server implement NAT in some way. On the router it is configured on the source interface for the external IP. On the strongswan server the server sits in a Amazon VPC (it is an EC2 instance) and there is an elastic IP attached to the instance.
Our Environment looks like this:
External IP: External IP:
+----------------+<<Cisco external IP>> <<AWS External IP>>+------------------+
| Cisco Router | | Centos 7 |
| ---------------------------------------------------- StrongSwan |
| |GRE Tunnel IP: GRE Tunnel IP: | |
+--------|-------+10.100.60.13/30 10.100.60.14/30 +---------|--------+
| |
| |
| |
| |
Internal Network Internal Network
192.168.0.0/16 192.168.1.0/24
Multicast Traffic
239.100.100.13
We are trying to setup a site-to-site vpn between a Cisco router and a centos 7 server running Strongswan 5.7.2-1.el7.
We are able to establish the ipsec tunnel, however the gre network 10.100.60.12/30 is not pingable. Further to this, while we see the multicast traffic via a tcpdump it appears to be 'caught' in the GRE encapsulation and does not provide data when subscribed to via a local process meant to connect to it:
strongswan]# tcpdump -n -s 0 -i eth0 not port 22
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
16:23:59.959925 IP <<Cisco external IP>>.ipsec-nat-t > 192.168.1.154.ipsec-nat-t: UDP-encap: ESP(spi=0xcf6ee5da,seq=0x1dc399), length 132
16:23:59.959925 IP <<Cisco external IP>> > <<AWS External IP>>: GREv0, length 76: IP 192.168.3.48.48146 > 239.100.100.13.9250: UDP, length 44
16:23:59.959942 IP <<Cisco external IP>>.ipsec-nat-t > 192.168.1.154.ipsec-nat-t: UDP-encap: ESP(spi=0xcf6ee5da,seq=0x1dc39a), length 132
16:23:59.959942 IP <<Cisco external IP>> > <<AWS External IP>>: GREv0, length 76: IP 192.168.3.48.48146 > 239.100.100.13.9250: UDP, length 44
16:23:59.960201 IP <<Cisco external IP>>.ipsec-nat-t > 192.168.1.154.ipsec-nat-t: UDP-encap: ESP(spi=0xcf6ee5da,seq=0x1dc39b), length 132
16:23:59.960201 IP <<Cisco external IP>> > <<AWS External IP>>: GREv0, length 76: IP 192.168.3.48.48146 > 239.100.100.13.9250: UDP, length 44
On the cisco router the following configuration is used:
crypto isakmp policy 300
encr 3des
authentication pre-share
group 2
lifetime 28800
!
crypto isakmp key <<key>> address <<AWS External IP>>
!
crypto ipsec transform-set RXN-3DES-SHA esp-3des esp-sha-hmac
mode tunnel
!
crypto map outside_map 999 ipsec-isakmp
description IPSec tunnel to newStrongSwanTestAws
set peer <<AWS External IP>>
set transform-set RXN-3DES-SHA
set pfs group2
match address NEWSTRONGSWANTEST
!
interface Tunnel999
description StrongSwantest GRE tunnel
ip address 10.100.60.13 255.255.255.252
ip mtu 1400
ip nat outside
ip pim neighbor-filter MCAST-DENY-ALL
ip pim sparse-dense-mode
ip tcp adjust-mss 1360
ip igmp static-group 239.100.100.13
tunnel source <<Cisco external IP>>
tunnel destination <<AWS External IP>>
ip virtual-reassembly
!
interface GigabitEthernet0/1/1
ip address <<Cisco external IP>> 255.255.255.128
ip nat outside
negotiation auto
no cdp enable
crypto map outside_map
no ip virtual-reassembly
!
ip access-list standard MCAST-DENY-ALL
deny any
!
ip access-list extended NEWSTRONGSWANTEST
permit gre host <<Cisco external IP>> host <<AWS External IP>>
permit gre host <<AWS External IP>> host <<Cisco external IP>>
StrongSwan configs:
iptables.conf
# ipsec.conf - strongSwan IPsec configuration file
config setup
charondebug="all"
conn van
type=tunnel #IPSec Type: Tunnel
authby=secret #Authentication via Shared Secret
left=%defaultroute #strongswan outside address
leftsubnet=0.0.0.0/0 #Local Subnets being Tunneled
leftid=<<AWS External IP>> #Connection PublicIP (OtherPartyConnectionId)
right=<<Cisco external IP>> #Remote Participant PublicIP
rightsubnet=0.0.0.0/0,239.100.100.13 #Remote Subnets being Tunneled
rightid=<<Cisco external IP>> #IKEID sent by IOS
auto=start
compress = yes
ike=3des-sha1-modp1024! #IKE Phase 1 Algorithm
esp=3des-sha-modp1024!
mark=%unique
ikelifetime=86400
keyingtries=%forever #Attempts to Negotiate a Connection
#keylife=59m
#rekeymargin=3m
rekey=yes #Enable Rekeying
keyexchange=ikev1
authby=secret
dpdtimeout=10 #Dead Peer Detection Timeout
dpddelay=3 #Dead Peer Detection Delay
ipsec.secrets
# ipsec.secrets - strongSwan IPsec secrets file
%any %any : PSK "<<key>>"
%any : PSK "<<key>>""
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
charon {
load_modular = yes
plugins {
include strongswan.d/charon/*.conf
}
}
include strongswan.d/*.conf
strongswan.d/starter.conf
starter {
# Location of the ipsec.conf file
config_file = /etc/strongswan/ipsec.conf
}
After starting strongswan status of the tunnels is as follows:
strongswan]# strongswan statusall
Status of IKE charon daemon (strongSwan 5.7.2, Linux 3.10.0-1062.12.1.el7.x86_64, x86_64):
uptime: 53 minutes, since Jan 21 15:45:19 2021
malloc: sbrk 1724416, mmap 0, used 603808, free 1120608
worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 5
loaded plugins: charon pkcs11 tpm aesni aes des rc2 sha2 sha1 md4 md5 mgf1 random nonce x509 revocation constraints acert pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl gcrypt fips-prf gmp curve25519 chapoly xcbc cmac hmac ctr ccm gcm curl attr kernel-netlink resolve socket-default farp stroke vici updown eap-identity eap-sim eap-aka eap-aka-3gpp eap-aka-3gpp2 eap-md5 eap-gtc eap-mschapv2 eap-dynamic eap-radius eap-tls eap-ttls eap-peap xauth-generic xauth-eap xauth-pam xauth-noauth dhcp led duplicheck unity counters
Listening IP addresses:
192.168.1.154
Connections:
van: %any...<<Cisco external IP>> IKEv1
van: local: [<<AWS External IP>>] uses pre-shared key authentication
van: remote: [<<Cisco external IP>>] uses pre-shared key authentication
van: child: 0.0.0.0/0 === 0.0.0.0/0 TUNNEL
Security Associations (1 up, 0 connecting):
van[2]: ESTABLISHED 53 minutes ago, 192.168.1.154[<<AWS External IP>>]...<<Cisco external IP>>[<<Cisco external IP>>]
van[2]: IKEv1 SPIs: 5d7341cbe0165876_i 44d5d21cf864ebb0_r*, pre-shared key reauthentication in 22 hours
van[2]: IKE proposal: 3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
van{3}: REKEYED, TUNNEL, reqid 1, expires in 6 minutes
van{3}: <<AWS External IP>>/32[gre] === <<Cisco external IP>>/32[gre]
van{4}: INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: cbe53fd4_i 530be7ab_o
van{4}: 3DES_CBC/HMAC_SHA1_96/MODP_1024, 62413730 bytes_i, 0 bytes_o, rekeying in 36 minutes
van{4}: <<AWS External IP>>/32[gre] === <<Cisco external IP>>/32[gre]
A gre tunnel is attempted to be created via the following command, but we are unsure if this is correct or not:
ip tunnel add 999 mode gre local 10.100.60.14 remote 10.100.60.13 ttl 255
ip link set 999 up
ip route add 10.100.60.12/30 dev 999
It should be noted that the multicast traffic appears to flow without the tunnel 999 interface being up on the strongswan server itself, so we are not sure that this interface is setup correctly at all.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20210121/11e56dd9/attachment-0001.html>
More information about the Users
mailing list