1
root@p10:/proc/net# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 16.04.3 LTS
Release:        16.04
Codename:       xenial

OVH Public Cloud Server, on OpenStack

Hello everyone,

I have weird behaviors with my iptables/NAT/16.04 installation.

OpenVPN is set up to receive connections and works properly. For some historical reasons, the VPN packets have to be egressed and translated on the WAN public interface ens33 (and use its address as source).

But the behavior of the Masquerade is not consistent.

For example, I enable the Masquerade, but it won't work right away. After few minutes (variable), it will start working. Then I remove the Masquerade, and it keeps working, for few minutes or maybe more.

All of this makes it hard for me to diagnose and implement further features (target goals is 2 VPNs NATed on 2 different public IP addresses)).

I really don't understand what's going on. If someone has a clue, please help!

Here's the detail :

Interfaces

ens3      Link encap:Ethernet  HWaddr 
          inet addr:54.38.X.X  

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:10.99.0.1  P-t-P:10.99.0.2  Mask:255.255.255.255

Filters

root@p10:/proc/net# iptables -L -vnx
Chain INPUT (policy DROP 53737 packets, 2988971 bytes)
    pkts      bytes target     prot opt in     out     source               destination
    6120   612989 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:587
(...)

Chain FORWARD (policy ACCEPT 433 packets, 39648 bytes)
    pkts      bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 10153 packets, 1034888 bytes)
    pkts      bytes target     prot opt in     out     source               destination

Masquerade

root@p10:/proc/net# iptables -t nat -L -vnx
Chain PREROUTING (policy ACCEPT 8367 packets, 465763 bytes)
    pkts      bytes target     prot opt in     out     source               destination

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 2 packets, 152 bytes)
    pkts      bytes target     prot opt in     out     source               destination

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination
       4      272 MASQUERADE  all  --  *      *       0.0.0.0/0            0.0.0.0/0

Forward

root@p10:/proc/net# sysctl -a | grep "\.forwarding" | grep ipv4
net.ipv4.conf.all.forwarding = 1
net.ipv4.conf.default.forwarding = 1
net.ipv4.conf.ens3.forwarding = 1
net.ipv4.conf.lo.forwarding = 1
net.ipv4.conf.tun0.forwarding = 1

Client

On my Windows VPN client, routes are pushed, for example to send packet to a test address 194.51.3.65 via the VPN :

Route print
      194.51.3.65  255.255.255.255      10.99.5.118      10.99.5.117    291

C:\Windows\system32>ping  194.51.3.65

Envoi d’une requête 'Ping'  194.51.3.65 avec 32 octets de données :
Réponse de 194.51.3.65 : octets=32 temps=26 ms TTL=48

Statistiques Ping pour 194.51.3.65:
    Paquets : envoyés = 1, reçus = 1, perdus = 0 (perte 0%),
Durée approximative des boucles en millisecondes :
    Minimum = 26ms, Maximum = 26ms, Moyenne = 26ms
Ctrl+C
^C
C:\Windows\system32>tracert -d 194.51.3.65

Détermination de l’itinéraire vers 194.51.3.65 avec un maximum de 30 sauts.

  1    16 ms    15 ms    25 ms  10.99.0.1
  2    19 ms    20 ms    17 ms  54.38.X.X
  3    18 ms    21 ms    17 ms  158.69.61.222
  4    61 ms    78 ms    15 ms  51.255.245.126
  5    14 ms    16 ms    35 ms  10.97.155.39

As you can see, the test ping packets are sent via the VPN and work well.

Now the strange behavior I have is this one:

  • either I remove the Masquerade, but the pings keep working

  • or I remove the Masquerade and the pings stop working, but when I re-enable the Masquerade, they don't work anywore. Sometimes I'll have to wait 10 seconds, sometimes 5 minutes.

Other behaviors

Also, I have other weird things :

  • I can see conntracks :

    root@p10:/proc/net# conntrack -L (...) conntrack v1.4.3 (conntrack-tools): 3 flow entries have been shown.

  • But I cannot see NAT sessions :

    root@p10:/proc/net# netstat-nat Could not read info about connections from the kernel, make sure netfilter is enabled in kernel or by modules. root@p10:/proc/net#

  • I suspect that your issue with netstat-nat not working is because it is old and expects to find either /proc/net /ip_conntrack or /proc/net/nf_conntrack to work from. However those files no exist as of a few releases ago. – Doug Smythies Apr 12 '18 at 21:20
  • 1
    Thank you @DougSmythies do you know where are the files now? – Bibelo Apr 13 '18 at 22:08
  • I am not aware that the files exist anywhere now. I could only figure out to use the conntrack program now. – Doug Smythies Apr 14 '18 at 15:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.