VPN integration with a 3rd party Cisco device

Question

Apologies if this set-up makes no sense. It makes no sense to me, but any assistance is greatly appreciated.

Background

I have a Payment provider who requires me to provide 2 IP addresses, and establish a VPN (this is M-Pesa Tanzania).

I have a bunch of cloud hosted Ubuntu servers at my disposal.

This is what I think they want:

This is what I have:

I have also tried with a subnet (from the cloud provider):

And I've tried with the my-side target server as a client of my VPN device:

The end goal is that they can query a HTTPS endpoint that I will put on 94.130.xx.xx (yes, that makes the entire VPN pointless afaik).

All that I can get from the M-Pesa side is one or two attempts a day at telnet 94.130.xx.xx 443 and they'll tell me if it connected or not. They won't give me any logs, configuration advice, or any other assistance.

A few days of searching and experimenting has yielded no success.

What I need

The server at 41.217.xx.xx should be able to call 94.130.xx.xx via their gateway at 197.250.xx.xx

Their setup insists that there be a VPN device at my end which is a different IP to my server. This is set up to be 159.69.xx.xx

I don't really care what the real network ends up like, as long as M-Pesa get what they expect.

What I have tried

I have strong-swan installed on 159.69.xx.xx configured with /etc/ipsec.config as below:

conn mpesa
    type=tunnel
    left=159.69.xx.xx
    leftid=159.96.xx.xx
    leftsubnet=94.130.xx.xx/32
    right=197.250.xx.xx
    rightid=197.250.xx.xx
    rightsubnet=41.217.xx.xx/32
    ikelifetime=8h
    lifetime=8h
    keyexchange=ikev2
    authby=secret
    closeaction=restart
    dpdaction=restart
    dpddelay=300s
    auto=start

I have the PSK setup, and I can get the connection up:

ipsec route mpesa
ipsec statusall

returns

Status of IKE charon daemon (strongSwan 5.9.5, Linux 5.15.0-41-generic, x86_64):
  uptime: 37 seconds, since Jul 26 12:42:22 2022
  malloc: sbrk 3174400, mmap 0, used 1312768, free 1861632
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 3
  loaded plugins: charon aesni aes rc2 sha2 sha1 md5 mgf1 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl fips-prf gmp agent xcbc hmac gcm drbg attr kernel-netlink resolve socket-default connmark stroke updown eap-mschapv2 xauth-generic counters
Listening IP addresses:
  159.69.xx.xx
  2a01:4f8:c0c:95a7::1
  172.17.xx.xx
Connections:
       mpesa:  159.69.xx.xx...197.250.xx.xx  IKEv2, dpddelay=300s
       mpesa:   local:  [159.96.xx.xx] uses pre-shared key authentication
       mpesa:   remote: [197.250.xx.xx] uses pre-shared key authentication
       mpesa:   child:  dynamic === 41.217.xx.xx/32 TUNNEL, dpdaction=restart
Routed Connections:
       mpesa{2}:  ROUTED, TUNNEL, reqid 1
       mpesa{2}:   159.69.xx.xx/32 === 41.217.xx.xx/32
Security Associations (1 up, 0 connecting):
       mpesa[1]: ESTABLISHED 37 seconds ago, 159.69.xx.xx[159.96.xx.xx]...197.250.xx.xx[197.250.xx.xx]
       mpesa[1]: IKEv2 SPIs: ace5850eaaa5eee5_i* 662ecd6b9b800036_r, pre-shared key reauthentication in 7 hours
       mpesa[1]: IKE proposal: AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048

On top of that base, I've tried every variant of this iptables tunnel that I can think of, and tried it without:

iptables --append INPUT -s 197.250.xx.xx -j ACCEPT
iptables --append INPUT -d 197.250.xx.xx -j ACCEPT
iptables --table mangle --append FORWARD -o Tunnel1 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

ip tunnel add Tunnel1 local 159.69.xx.xx remote 197.250.xx.xx mode vti key 42

ip addr add 94.130.xx.xx/32 remote 41.217.xx.xx/32 dev Tunnel1
ip addr add 41.217.xx.xx/32 remote 94.130.xx.xx/32 dev Tunnel1
ip link set Tunnel1 up mtu 1419

sysctl -w net.ipv4.conf.Tunnel1.disable_policy=1
iptables --table mangle --append FORWARD -m policy --pol ipsec --dir in -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1361:1536 -j TCPMSS --set-mss 1360
iptables --table mangle --append FORWARD -m policy --pol ipsec --dir out -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1361:1536 -j TCPMSS --set-mss 1360

I also tried setting up another VPN on 94.130.108.249 and tunnelling that to my 'VPN' at 159.69.xx.xx; and I've tried looping the VPN connection back on itself to make 159.69.xx.126 look like 94.139.108.249 -- but I'm pretty sure I didn't do it properly.

Answer 1

too long for a comment, but please ask detail from your provider. In most situation it's a simple Site-to-Site VPN to do. You are overthinking it at the moment.

The end goal is that they can query a HTTPS endpoint that I will put on 94.130.108.249 (yes, that makes the entire VPN pointless afaik).

It's not pointless, as it double protect your webserver, you have HTTPS to protects the traffic and you have the Tunnel to protect the identity of who connect to that said server.

Your VPN device should connect to the provider VPN device, and in the configuration you expose the server subnet you want them to access. Your provider must expose the same set as you (right/left)

After that the routing should be configured, the remote endpoint will know that for talking to 91.* it need to talk inside the VPN. That imply that your endpoint can talk directly to the 91.* server.

Answer 2

Just in case someone comes across this...

I think the core of my problem was that the Network on the cloud hosted machines was already virtualised, so I had two different ip tunnel instances that couldn't talk to each other without causing self-feedback.

I never did work out how to do it with Linux + StrongSwan.

Being more of a dev than a network tech, I decided to write a virtualised VPN software. This is probably the dumbest thing I've ever had to do, but I couldn't find another way.

https://github.com/i-e-b/VirtualVpn