-4

I'm trying to set up an IPSEC tunnel between my remote external server and a locally situated machine. My remote has a naked public IP4 in a data-centre. My nearby server has a local NAT hidden 192.168.x.y address, however I have forwarded all the required ports and protocols to it; UDP 500, UDP 4500, ah, esp, as well as removing the router helper bindings. Both are running Debian 9 Stretch. My router is fine, that is sorted out already. The remote server can see the local on ESP, AH and IKE using nmap.

On the local, I did this (internal 100 range IP changed)

modprobe dummy
ip link add name dummy0 type dummy
ip address add 100.64.1.1/32 dev dummy0

and when I do 

ifconfig

it shows up like this

dummy0: flags=195<UP,BROADCAST,RUNNING,NOARP>  mtu 1500
        inet 100.64.1.1  netmask 255.255.255.255  broadcast 0.0.0.0
        inet6 fe80::xxxx:xxxx:xxxx:xxxx  prefixlen 64  scopeid 0x20<link>
        ether xx:xx:xx:xx:xx:xx  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 189  bytes 70950 (69.2 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

When we go to the external server,

modprobe dummy

it shows up with lsmod:

root@host:~# lsmod  | grep dummy
dummy                  16384  0
root@host:~#

, and the ifconfig command shows no dummy virtual ethernet port, after performing a similar set of subsequent commands.

Why is dummy0 not showing?

Any ideas what is wrong?

[Edit- added 13/10/2018 22:18 BST] I've added this diagram for clarity. This is what I'm setting up:

Description of Data Centre to Locally hosted IPSEC tunnel solution with StrongSwan on Debian 9. The tunnel for Cyrus replication is up.

birdwes
  • 88
  • 1
  • 1
  • 12
  • Why the downvote? – birdwes Oct 12 '18 at 00:37
  • Questions on Server Fault must be about managing information technology systems in a business environment. Home and end-user computing questions may be asked on Super User, and questions about development, testing and development tools may be asked on Stack Overflow. – Davidw Oct 12 '18 at 01:21
  • The raspberrypi stack exchange: https://raspberrypi.stackexchange.com/ – Davidw Oct 12 '18 at 01:23
  • This problem is with the x64 server, not the Pi, besides which, though it may be "home" for me, this is a business environment. I regularly deploy Pi in business. – birdwes Oct 12 '18 at 06:09
  • 1
    This question is very confusing. It first talks about running IPSec through NAT then proceeds to ask about the dummy interface. And it is tagged `iptables`. Which of those three totally different subjects is the question about? And which kernel version are you experiencing problems on anyway? – kasperd Oct 12 '18 at 08:05
  • The remote with the problem is 4.9.0-8-amd64 #1 SMP Debian 4.9.110-3+deb9u6, I haven't got on to the iptables part yet. The reason for the dummy interface is to loop around firewall with iptables mark and mangle as if it is a second network adapter, which is the normal scenario I've done before with racoon, but racoon seems to have fallen out of favour. This will be a strongswan implementation and the service will have to bind to the IP on the dummy virtual interface. – birdwes Oct 12 '18 at 08:14
  • @kasperd - It's all up and running now. The VPN tunnel is in place. – birdwes Oct 12 '18 at 13:57

1 Answers1

1

The reason for originally choosing the "dummy" eth adapter, was as described here:

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

"There is no need to create additional interfaces (like TUN) or aliases (like eth0:1, which are an old concept anyway). If you want to use private IP addresses inside the IPsec tunnels just add them to one of the existing interfaces (eth0 or lo) using ip addr add".

So, I need to bind the tunnel IP endpoint to an adapter. I did not want to bind it to eth0, because that bears the server's public IP. It seems "wrong" to bind it to lo. So I originally chose to try to create dummy0.

From experiences of people with many different distributions and platforms, it seems that the dummy interface is intermittently unreliable, as well as being very difficult to reliably start in a boot time script. That is what I found too.

https://bugzilla.redhat.com/show_bug.cgi?id=1120823

https://askubuntu.com/questions/994669/why-does-ip-link-add-not-work-in-rc-local

https://unix.stackexchange.com/questions/335284/how-can-we-create-multiple-dummy-interfaces-on-linux

https://community.nethserver.org/t/virtual-network-interface-for-virtual-machines/7728/10

My working solution creates a TUN device. Even though no packets flow through it, it works as a reliable binding point for the IP address at each endpoint. Whilst this is still not the recommended practice, I find that it provides obvious insight as to why the address is bound to it, when you type 

ifconfig

TUN is easy and reliable to bring up in system boot scripts.

In my question's diagram, substitute dummy0: for tun0: for a working solution.

Use something like this:

ip tuntap add name tun0 mode tun
ip link set dev tun0 up
ip address add 100.64.2.1/32 dev tun0
route add -net 100.64.1.0/24 gw 100.64.2.1

to bring the IP endpoint binding up.

[Edit 17/09/2018 00:50] Cyrus mailbox replication is working perfectly now.

birdwes
  • 88
  • 1
  • 1
  • 12