Accessing MultiTech Conduit Web Interface and SSH over OpenVPN

[Marco Meier]

We have configured OpenVPN on the MultiTech Conduit. The Tunnel is up and running. From the MultiTech Conduit we can ping other devices. But the opposite direction is not working. The other devices cannot ping the MultiTech Conduit over OpenVPN. Also, SSH connection from the other devices to the MultiTech Conduit is not possible.
I created the following Firewall rule on the MultiTech Conduit, with the Web Interface:

Chain USER_INPUT (1 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     tcp  --  tunA tunA 0.0.0.0/0            0.0.0.0/0            tcp dpt:22
    0     0 ACCEPT     tcp  --  tunA tunA 0.0.0.0/0            0.0.0.0/0            tcp dpt:80
    0     0 ACCEPT     tcp  --  tunA tunA 0.0.0.0/0            0.0.0.0/0            tcp dpt:443
    0     0 ACCEPT     udp  --  tunA tunA 0.0.0.0/0            0.0.0.0/0            udp dpt:22
    0     0 ACCEPT     udp  --  tunA tunA 0.0.0.0/0            0.0.0.0/0            udp dpt:80
    0     0 ACCEPT     udp  --  tunA tunA 0.0.0.0/0            0.0.0.0/0            udp dpt:443
    0     0 ACCEPT     all  --  *      tunA 0.0.0.0/0            0.0.0.0/0

I also enabled SSH and ICMP for LAN and WAN, and I disabled all IP Defense protection.
But no success. Do I miss something? Or what settings are needed to access (Web and SSH) and ping the MultiTech Conduit over OpenVPN?
Other OpenVPN clients can be accessed/pinged over OpenVPN. Therefore , I think it’s no a OpenVPN server issue. I use Firmware 5.3.0.

Below some more information:
If I do a tcpdump at the OpenVPN interface, I see, how I receive the ICMP echo request from the other device but there is no answer from MultiTech Conduit:

root@mtcdt:~# tcpdump -nni tunA
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tunA, link-type RAW (Raw IP), capture size 262144 bytes
16:41:17.162801 IP 10.8.0.82 > 10.8.0.218: ICMP echo request, id 1, seq 1371, length 40
16:41:22.174566 IP 10.8.0.82 > 10.8.0.218: ICMP echo request, id 1, seq 1372, length 40
16:41:27.174088 IP 10.8.0.82 > 10.8.0.218: ICMP echo request, id 1, seq 1373, length 40
16:41:32.198163 IP 10.8.0.82 > 10.8.0.218: ICMP echo request, id 1, seq 1374, length 40

If I ping from the MultiTech Conduit to the other device everything looks good.

root@mtcdt:~# tcpdump -nni tunA icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tunA, link-type RAW (Raw IP), capture size 262144 bytes
16:19:14.255395 IP 10.8.0.218 > 10.8.0.82: ICMP echo request, id 1916, seq 1, length 64
16:19:14.279147 IP 10.8.0.82 > 10.8.0.218: ICMP echo reply, id 1916, seq 1, length 64
16:19:15.257082 IP 10.8.0.218 > 10.8.0.82: ICMP echo request, id 1916, seq 2, length 64
16:19:15.284534 IP 10.8.0.82 > 10.8.0.218: ICMP echo reply, id 1916, seq 2, length 64
16:19:16.258618 IP 10.8.0.218 > 10.8.0.82: ICMP echo request, id 1916, seq 3, length 64
16:19:16.274599 IP 10.8.0.82 > 10.8.0.218: ICMP echo reply, id 1916, seq 3, length 64

Same result if a SSH connection to the MultiTech Conduit is opened. I see the TCP SYN request but no answer from the MultiTech Conduit.

root@mtcdt:~# tcpdump -nni tunA
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tunA, link-type RAW (Raw IP), capture size 262144 bytes
16:33:27.173574 IP 10.8.0.82 > 10.8.0.218: ICMP echo request, id 1, seq 1274, length 40
16:33:32.183251 IP 10.8.0.82 > 10.8.0.218: ICMP echo request, id 1, seq 1275, length 40
16:33:35.094742 IP 10.8.0.82.49821 > 10.8.0.218.22: Flags [S], seq 2958590557, win 64240, options [mss 1357,nop,wscale 8,nop,nop,sackOK], length 0
16:33:37.182495 IP 10.8.0.82 > 10.8.0.218: ICMP echo request, id 1, seq 1276, length 40
16:33:38.095533 IP 10.8.0.82.49821 > 10.8.0.218.22: Flags [S], seq 2958590557, win 64240, options [mss 1357,nop,wscale 8,nop,nop,sackOK], length 0
16:33:42.182415 IP 10.8.0.82 > 10.8.0.218: ICMP echo request, id 1, seq 1277, length 40
16:33:44.092039 IP 10.8.0.82.49821 > 10.8.0.218.22: Flags [S], seq 2958590557, win 64240, options [mss 1357,nop,wscale 8,nop,nop,sackOK], length 0
16:33:47.176766 IP 10.8.0.82 > 10.8.0.218: ICMP echo request, id 1, seq 1278, length 40

Routing table and open ports:

root@mtcdt:~# ifconfig
eth0      Link encap:Ethernet  HWaddr 00:08:00:4A:F4:1D
          inet addr:10.1.1.200  Bcast:10.1.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:8509 errors:0 dropped:3158 overruns:0 frame:0
          TX packets:5244 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:842258 (822.5 KiB)  TX bytes:2521059 (2.4 MiB)
          Interrupt:28 Base address:0xc000

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:49535 errors:0 dropped:0 overruns:0 frame:0
          TX packets:49535 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1
          RX bytes:5390752 (5.1 MiB)  TX bytes:5390752 (5.1 MiB)

ppp0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:10.1.58.114  P-t-P:10.1.58.114  Mask:255.255.255.252
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1430  Metric:1
          RX packets:14 errors:0 dropped:0 overruns:0 frame:0
          TX packets:16 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:2662 (2.5 KiB)  TX bytes:2001 (1.9 KiB)

tunA Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:10.8.0.218  P-t-P:10.8.0.217  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:607 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:36396 (35.5 KiB)  TX bytes:0 (0.0 B)
root@mtcdt:~# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.1.1.1        0.0.0.0         UG    0      0        0 eth0
10.1.1.0        0.0.0.0         255.255.255.0   U     0      0        0 eth0
10.1.58.112     0.0.0.0         255.255.255.252 U     0      0        0 ppp0

10.8.0.0        10.8.0.217      255.255.255.0   UG    0      0        0 tunA
10.8.0.217      0.0.0.0         255.255.255.255 UH    0      0        0 tunA
root@mtcdt:~# netstat -tulpn | grep LISTEN
netstat: showing only processes with your user ID
tcp        0      0 127.0.0.1:2947          0.0.0.0:*               LISTEN      1227/gpsd
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      1476/lighttpd
tcp        0      0 0.0.0.0:53              0.0.0.0:*               LISTEN      3291/dnsmasq
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      1974/sshd
tcp        0      0 127.0.0.1:1883          0.0.0.0:*               LISTEN      1539/mosquitto
tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN      1476/lighttpd
tcp        0      0 ::1:2947                :::*                    LISTEN      1227/gpsd
tcp        0      0 :::53                   :::*                    LISTEN      3291/dnsmasq
tcp        0      0 :::22                   :::*                    LISTEN      1974/sshd
tcp        0      0 :::443                  :::*                    LISTEN      1476/lighttpd

• This topic was modified 2 years, 11 months ago by Marco Meier.
• This topic was modified 2 years, 11 months ago by Marco Meier.
• This topic was modified 2 years, 11 months ago by Marco Meier.
• This topic was modified 2 years, 11 months ago by Marco Meier.

[Jeff Hatch]

Hello Marco,

On comment on the INPUT rules: we are not sure that you need to specify the out interface on the rules. I am not positive, but that seems like it might cause issues. In the iptables man page for the -o (–out-interface) option it really only specifies using that option on FORWARD, OUTPUT, and POSTROUTING chains. See https://linux.die.net/man/8/iptables and specifically:

-o, --out-interface [!] name
Name of an interface via which a packet is going to be sent (for packets entering the FORWARD, OUTPUT and POSTROUTING chains). When the "!" argument is used before the interface name, the sense is inverted. If the interface name ends in a "+", then any interface which begins with this name will match. If this option is omitted, any interface name will match.

I am not sure exactly what effect specifying the output interface on the input rule would have in this situation.

Thank You,

Jeff

[Marco Meier]

Hi Jeff

Ooh, you are right. I do not need to specify my output interface for an input rule. Removing this entry, fixed my issue.
Thanks!
Marco

[Author]

Posts