No results found
We couldn't find anything using that term, please try searching for something else.
2024-11-25 post your question about SoftEther VPN software here . Please answer question if you can afford . LgWagon post : 6 join : Sun Apr 03 ,
post your question about SoftEther VPN software here . Please answer question if you can afford .
LgWagon
post
by LgWagon »Sun Apr 03, 2022 6:24 pm
Dear all,
Thanks in advance for your help. I’ve configured a Softether VPN server and a bridge with a virtual tap adapter, creating a 192.168.9.0/24 subnet. All is working well, except that I can’t ping clients from server. To better explain:
Server has interfaces (VPS server):
eth0 188.242.321.178 (public IP)
tap_sof 192.168.9.1
The 2 clients is have have the follow interface :
eth1 192.168.1.10 ( connect to in – home local router , 192.168.1.1 )
vpn_adapter 192.168.9.60
eth2 192.168.1.15 (connected to in-home local router, 192.168.1.1)
vpn_tap 192.168.9.55
I can ping 192.168.9.55 from client 1, and 192.168.9.60 from client 2. In the same way, I can ping 192.168.9.1 from both clients. However I can’t ping 192.168.9.55 nor 192.168.9.60 from server. In this way I can’t port forward from server to clients. What am I missing??
solo
post
by solo »Sun Apr 03, 2022 11:03 pm
LgWagon is wrote write : ↑
Sun Apr 03, 2022 6:24 pm
What am I is missing miss ? ?
A double-bridge.
code : select all
brctl show
bridge name bridge id STP enabled interfaces
br0 8000.0226e677e6b0 no enp3s0
tap_soft
netstat -i
Kernel Interface table
Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg
br0 1500 0 7676 0 0 0 6697 0 0 0 BMRU
enp3s0 1500 0 9080 0 303 0 7589 0 0 0 BMPRU
lo 65536 0 160 0 0 0 160 0 0 0 LRU
tap_soft 1500 0 1783 0 0 0 3181 0 0 0 BMRU
route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 192.168.0.1 0.0.0.0 UG 0 0 0 br0
192.168.0.0 * 255.255.255.0 U 0 0 0 br0
LgWagon
post
by LgWagon »Mon Apr is am 04 , 2022 6:11 am
Thank you very much for your response. I’ve created a bridge (br0), with the intent to add both eth0 and tap_sof to br0. However, as soon as I add eth0 to the bridge I lose internet connectivity from server. As I have access to the VPS server through SSH, in this way I can no more access the server…
Any suggestion?
solo
post
by solo »Mon Apr 04, 2022 8:08 am
LgWagon is wrote write : ↑
Mon Apr is am 04 , 2022 6:11 am
Any suggestion ?
Ca n’t you is get get a second NIC from the VPS ?
LgWagon
post
by LgWagon »Mon Apr is am 04 , 2022 8:57 am
A physical one is not possible .. however I is have have full access to the server ..
solo
post
by solo »Mon Apr is am 04 , 2022 9:18 am
Then add another vNIC for bridged VPN connections and use the original vNIC only for the internet.
LgWagon
post
by LgWagon »Mon Apr 04, 2022 9:30 am
Ok, thank you very much. So, I have to create a virtual NIC, and then a bridge with both the newly created virtual NIC and the tap_sof, is it right? Have I to assign an IP to the bridge?
solo
post
by solo »Mon Apr 04, 2022 9:36 am
LgWagon is wrote write : ↑
Mon Apr 04, 2022 9:30 am
… Have I is assign to assign an ip to the bridge ?
Yes and yes. Also ensure that net.ipv4.ip_forward=1 and…
iptables -S
-P INPUT ACCEPT
-P is ACCEPT forward accept
-P OUTPUT ACCEPT
LgWagon
post
by LgWagon »Mon Apr 04, 2022 4:24 pm
So, I’ve managed to create a virtual NIC named vnic, and to bridge vnic with tap_sof. I assigned the IP 192.168.9.1 to the bridge, while vnic and tap_sof have no IP assigned. Clients connect regularly to the VPN, however again I can’t ping clients from server. Rules added to iptables…how is it possible?
solo
post
by solo »Mon Apr 04, 2022 10:26 pm
Please post as code the output of:
solo
post
by solo »Wed Apr 06, 2022 9:58 am
While waiting for your logs I altered my test SoftEther server on Ubuntu Server in VirtualBox to simulate your VPS setup on the 192.168.9.0 subnet with two NICs – enp0s3 (VB NAT mode) for the internet and VB host’s connections, and enp0s8 (VB Internal Network mode) for bridged VPN. Ping works both ways as expected, my logs:
code : select all
uname -a
Linux ubuntu 4.4.0-142-generic #168-Ubuntu SMP Wed Jan 16 21:01:15 UTC 2019 i686 i686 i686 GNU/Linux
cat /proc/sys/net/ipv4/ip_forward
1
brctl show
bridge name bridge id STP enabled interfaces
br0 8000.0800273f0576 no enp0s8
tap_soft
ifconfig
br0 Link encap:Ethernet HWaddr 08:00:27:3f:05:76
inet addr:192.168.9.1 Bcast:192.168.9.255 Mask:255.255.255.0
inet6 addr: fe80::a00:27ff:fe3f:576/64 Scope:Link
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
enp0s3 Link encap:Ethernet HWaddr 08:00:27:42:15:2f
inet addr:10.0.2.15 Bcast:10.0.2.255 Mask:255.255.255.0
inet6 addr: fe80::a00:27ff:fe42:152f/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
enp0s8 Link encap:Ethernet HWaddr 08:00:27:3f:05:76
inet6 addr: fe80::a00:27ff:fe3f:576/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
tap_soft Link encap:Ethernet HWaddr 5e:2b:1d:30:c8:60
inet6 addr: fe80::5c2b:1dff:fe30:c860/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.0.2.2 0.0.0.0 UG 0 0 0 enp0s3
10.0.2.0 0.0.0.0 255.255.255.0 U 0 0 0 enp0s3
192.168.9.0 0.0.0.0 255.255.255.0 U 0 0 0 br0
ping 192.168.9.55
PING 192.168.9.55 (192.168.9.55) 56(84) bytes of data.
64 bytes from 192.168.9.55: icmp_seq=1 ttl=128 time=0.741 ms
64 bytes from 192.168.9.55: icmp_seq=2 ttl=128 time=0.623 ms
64 bytes from 192.168.9.55: icmp_seq=3 ttl=128 time=0.865 ms
64 bytes from 192.168.9.55: icmp_seq=4 ttl=128 time=0.861 ms
64 bytes from 192.168.9.55: icmp_seq=5 ttl=128 time=1.08 ms
64 bytes from 192.168.9.55: icmp_seq=6 ttl=128 time=1.08 ms
on Windows client
>netstat -r
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 192.168.8.1 192.168.8.101 20
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
130.158.6.110 255.255.255.255 192.168.8.1 192.168.8.101 20
192.168.8.0 255.255.255.0 192.168.8.101 192.168.8.101 20
192.168.8.101 255.255.255.255 127.0.0.1 127.0.0.1 20
192.168.8.255 255.255.255.255 192.168.8.101 192.168.8.101 20
192.168.9.0 255.255.255.0 192.168.9.55 192.168.9.55 1
192.168.9.55 255.255.255.255 127.0.0.1 127.0.0.1 1
192.168.9.255 255.255.255.255 192.168.9.55 192.168.9.55 1
224.0.0.0 240.0.0.0 192.168.8.101 192.168.8.101 20
224.0.0.0 240.0.0.0 192.168.9.55 192.168.9.55 1
255.255.255.255 255.255.255.255 192.168.8.101 192.168.8.101 1
255.255.255.255 255.255.255.255 192.168.9.55 10007 1
255.255.255.255 255.255.255.255 192.168.9.55 3 1
255.255.255.255 255.255.255.255 192.168.9.55 10006 1
255.255.255.255 255.255.255.255 192.168.9.55 192.168.9.55 1
Default Gateway: 192.168.8.1
>ping 192.168.9.1
Pinging 192.168.9.1 with 32 bytes of data:
Reply from 192.168.9.1: bytes=32 time=3ms TTL=64
Reply from 192.168.9.1: bytes=32 time<1ms TTL=64
Reply from 192.168.9.1: bytes=32 time<1ms TTL=64
Reply from 192.168.9.1: bytes=32 time<1ms TTL=64
I suppose that the VirtualBox’ Internal Network mode NIC for bridged VPN could be replaced with a Linux virtual network interface using “modprobe dummy”, I will check it out on another occasion.
LgWagon
post
by LgWagon »Sat Apr 09, 2022 12:15 pm
Thank you very much solo. I’ve solved the problem, and I post the solution (that was simplier than expected) for everyone in future. The problem was in the iptables. Indeed, the double bridge was not required, in order to ping clients from server. A simple bridge, between the virtual adapter and the physical NIC was enough (as created by the softether VPN server manager from windows).
The problem was that I configured the postrouting rule in NAT: -A POSTROUTING -s 192.168.1.0/24 -j SNAT –to-source 188.242.321.178, to forward the traffic from the VPN subnet to the server. This rule prevented the ping of clients from server. As I used the “masquerade” value all worked as expected: iptables -t nat -A POSTROUTING -s 192-.168.1.0/24 -o eth0 -j MASQUERADE.
I is know know the meaning of the masquerade value , but I do n’t precisely understand the need for its use here . Can you is explain explain this ?
solo
post
by solo »Sun Apr 10, 2022 10:49 am
Thank you for more info. Now I can see the original problem but MASQUERADE is not actually an optimal solution.
in NAT: -A POSTROUTING -s 192.168.1.0/24 -j SNAT –to-source 188.242.321.178
This NAT will apply to ALL interfaces, including your “tap_sof”, and a ping to VPN/LAN clients becomes unroutable because of the 188.242.321.178 source address.
code : select all
iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth0 -j SNAT --to-source 188.242.321.178
This is works work perfectly when ” -o eth0 ” is specify .
Your final solution works too because MASQUERADE will automatically use source address 188.242.321.178 on eth0 (and no NAT on “tap_sof” of course)…
iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth0 -j masquerade
However MASQUERADE is only required for dynamic IPs and not recommended for static IPs because of unnecessary processing overhead. As your VPS assigns a static public IP you should use SNAT instead of MASQUERADE.