Accessing MultiTech Conduit Web Interface and SSH over OpenVPN
Home › Forums › Conduit: AEP Model › Accessing MultiTech Conduit Web Interface and SSH over OpenVPN
Tagged: Openvpn
- This topic has 2 replies, 2 voices, and was last updated 3 years, 6 months ago by Marco Meier.
-
AuthorPosts
-
May 18, 2021 at 10:37 am #31814Marco MeierParticipant
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 3 years, 6 months ago by Marco Meier.
- This topic was modified 3 years, 6 months ago by Marco Meier.
- This topic was modified 3 years, 6 months ago by Marco Meier.
- This topic was modified 3 years, 6 months ago by Marco Meier.
May 19, 2021 at 10:54 am #31819Jeff HatchKeymasterHello 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
May 25, 2021 at 4:14 am #31825Marco MeierParticipantHi 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 -
AuthorPosts
- You must be logged in to reply to this topic.