[strongSwan] Site-to-Site VPN - GRE over IPSec - Multicast - Cisco Router to StrongSwan (Centos 7) Issues

2021-01-21 Thread Rx Networks - Netops
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 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 <>.ipsec-nat-t > 
192.168.1.154.ipsec-nat-t: UDP-encap: ESP(spi=0xcf6ee5da,seq=0x1dc399), length 
132
16:23:59.959925 IP <> > <>: GREv0, length 
76: IP 192.168.3.48.48146 > 239.100.100.13.9250: UDP, length 44
16:23:59.959942 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 <> > <>: GREv0, length 
76: IP 192.168.3.48.48146 > 239.100.100.13.9250: UDP, length 44
16:23:59.960201 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 <> > <>: 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 <> address <>
!
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 <>
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 <>
tunnel destination <>
ip virtual-reassembly
!
interface GigabitEthernet0/1/1
ip address <> 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 <> host <>
permit gre host <> host <>

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=<>  #Connection PublicIP 
(OtherPartyConnectionId)
right=<>   #Remote Participant PublicIP
rightsubnet=0.0.0.0/0,239.100.100.13 #Remote Subnets being Tunneled
rightid=<>#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 

Re: [strongSwan] Performance of libipsec in strongswan ( kernel-vpp plugin )

2021-01-21 Thread Noel Kuntze

Hello Venu,

I am not aware of anything in that regard. It should be adressable though.
Tobias has actual insight to any internal roadmap (I do not).

Kind regards

Noel

Am 21.01.21 um 06:50 schrieb Venumadhav Josyula:

Hi Noel,

Thanks for the quick response. Is there something in the roadmap to address 
this case ?

Thanks,
Regards,
Venu

On Thu, 21 Jan 2021 at 10:37, Noel Kuntze 
 wrote:

Hello Venu,

That is still the case.

Kind regards

Noel

Am 21.01.21 um 05:52 schrieb Venumadhav Josyula:
 > Hi Tobias,
 >
 > In 'Issue #964', you mentioned it was not intended for high volume 
traffic. Is this still the case in lastest strongswan too. Meaning we have vpp 
based stack, where we want to use kernel-vpp plugin for the same. In other words, 
I want to know if it can be used in security gateways.
 >
 > Any pointers would be appreciated.
 >
 > Thanks,
 > Regards,
 > Venu





OpenPGP_signature
Description: OpenPGP digital signature


Re: [strongSwan] Performance of libipsec in strongswan ( kernel-vpp plugin )

2021-01-21 Thread Noel Kuntze

Hello Venu,

That is still the case.

Kind regards

Noel

Am 21.01.21 um 05:52 schrieb Venumadhav Josyula:

Hi Tobias,

In 'Issue #964', you mentioned it was not intended for high volume traffic. Is 
this still the case in lastest strongswan too. Meaning we have vpp based stack, 
where we want to use kernel-vpp plugin for the same. In other words, I want to 
know if it can be used in security gateways.

Any pointers would be appreciated.

Thanks,
Regards,
Venu




OpenPGP_signature
Description: OpenPGP digital signature