I have system-on-a-chip device (https://www.olimex.com/wiki/A10-OLinuXino-LIME) which connects to the internet through 3g usb modem. Obviously 3g clients are firewalled behind the mobile operator's network so I need a way to traverse the firewall in order to connect to the device from the public internet.
Basically I need a point-to-point connection to the device so I can for example ssh to it. I do not care for the actual layer2 hub features.
SoftEther's NAT-T works great but I have another problem. The problem seems to be specific to the ARM distribution. I tested the same setup with server running on windows and x86 linux and it works ok. Here is the info for the SoC device:
1. Debian GNU/Linux 7
2.
eth0 Link encap:Ethernet HWaddr 02:d7:0a:43:1d:5b
inet addr:192.168.66.70 Bcast:192.168.66.255 Mask:255.255.255.0
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:18171 errors:0 dropped:0 overruns:0 frame:0
TX packets:6875 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2331507 (2.2 MiB) TX bytes:1246123 (1.1 MiB)
Interrupt:55 Base address:0xb000
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:24501 errors:0 dropped:0 overruns:0 frame:0
TX packets:24501 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:3602181 (3.4 MiB) TX bytes:3602181 (3.4 MiB)
ppp0 Link encap:Point-to-Point Protocol
inet addr:10.178.255.118 P-t-P:10.64.64.64 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:15918 errors:3 dropped:0 overruns:0 frame:0
TX packets:21328 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:3408804 (3.2 MiB) TX bytes:4060803 (3.8 MiB)
3.
Linux Konst 3.4.90 #4 PREEMPT Wed May 20 03:28:24 EEST 2015 armv7l GNU/Linux
4.
softether-vpnserver-v4.15-9546-beta-2015.04.05-linux-arm_eabi-32bit.tar.gz
5. Which SoftEther VPN component are you using?
Server, Client
6. Whether or not there is a NAT or Firewall between your VPN server and the Internet.
YES
7. Are you using SecureNAT?
See below
The device is connected to the internet through the 3g ppp0 interface. Eth0 is the ethernet port of the device which is connected to other local stuff (but I repeat that I need only access to the device - ssh).
I tried several scenarios.
1/ Local bridge with eth0
I expected that I could connect at the device's eth0 address - 192.168.66.70.
It works on windows and linux x86 but not on the SoC.
It is very interesting that I can access every other device in the 192.168.66.x network but not the server's ip.
2/ Local bridge with TAP interface.
The same things: works on win and lin x86 but not on the device. I set static ip to the server's tap interface but i can neither ping it nor open a tcp port from the client (also with proper static ip).
3/ Finally there is one scenario which worked for me:
* Remove all local bridges.
* Enable SecureNAT (I use it for the DHCP server, not for the NAT)
* Install vpnclient on the device and connect to itself (the server running on localhost). Thus the device gets another interface (the ip address is static):
vpn_vpn Link encap:Ethernet HWaddr 00:ac:91:ca:ea:c9
inet addr:192.168.30.2 Bcast:192.168.30.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:7046 errors:0 dropped:653 overruns:0 frame:0
TX packets:2694 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:548983 (536.1 KiB) TX bytes:501801 (490.0 KiB
* Connect with a normal client (gets its address through dhcp).
Now I can connect normally to 192.168.30.2
So I found a solution to my problem (scneario 3) and now I can access my device from the public internet. Well, I still have to run a vpnclient connecting to localhost on the device, which seems redundant, but at least it works.
Yet I decided to write here and see if there are some ideas why scenarios 1 and 2 do not work. It seems that it is quite specific to the arm distro but still it boils down to this: when using bridged configurations the clients can access everyone in the segment *except* the server's ip in the bridge.
Thank you!
ARM Point to Point VPN issue
-
- Posts: 3
- Joined: Wed May 27, 2015 9:10 pm
ARM Point to Point VPN issue
You do not have the required permissions to view the files attached to this post.
-
- Posts: 3
- Joined: Wed May 27, 2015 9:10 pm
Re: ARM Point to Point VPN issue
Today I found another scenario which can be used for point-to-point connections:
At the linux console:
* create alias of the loopback interface. For example
ip addr add 10.0.0.1/32 dev lo
At the VPN Server:
* Remove any local bridges
* Enable SecureNat - Both NAT and DHCP (with default gw OR static routes to 10.0.0.1/32, 192.168.66.0/24 etc.)
If we check the status of the SecureNAT and Kernel Mode NAT is *active* then pinging 10.0.0.1 will *not* work. Also pinging 192.168.66.70 (device's eth0 address) is not working. But again accessing anything *else* in the 192.168.66.x network is OK.
And then if we:
* From the hub extended options set DisableKernelModeSecureNAT to 1 - everything starts to work!
With the User mode NAT we can access the loopback address 10.0.0.1 and also 192.168.66.70.
By the way this behavior is the same also on Linux 86 as long is kernel mode nat is on. With server running on Windows pinging the local interfaces does not work even with kernel mode on.
At the linux console:
* create alias of the loopback interface. For example
ip addr add 10.0.0.1/32 dev lo
At the VPN Server:
* Remove any local bridges
* Enable SecureNat - Both NAT and DHCP (with default gw OR static routes to 10.0.0.1/32, 192.168.66.0/24 etc.)
If we check the status of the SecureNAT and Kernel Mode NAT is *active* then pinging 10.0.0.1 will *not* work. Also pinging 192.168.66.70 (device's eth0 address) is not working. But again accessing anything *else* in the 192.168.66.x network is OK.
And then if we:
* From the hub extended options set DisableKernelModeSecureNAT to 1 - everything starts to work!
With the User mode NAT we can access the loopback address 10.0.0.1 and also 192.168.66.70.
By the way this behavior is the same also on Linux 86 as long is kernel mode nat is on. With server running on Windows pinging the local interfaces does not work even with kernel mode on.