Archive Calculate
Can’t ping clients from server

Can’t ping clients from server

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 ,

Related articles

How to Setup a VPN on Linux 3.6: Electron Arrangement- The Bohr Model (Orbits) How to set up OpenVPN GUI app on Windows

post your question about SoftEther VPN software here . Please answer question if you can afford .

LgWagon

post : 6
join : Sun Apr 03 , 2022 6:06 pm

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 : 1511
join : Sun Feb 14 , 2021 10:31 am

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 : 6
join : Sun Apr 03 , 2022 6:06 pm

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 : 1511
join : Sun Feb 14 , 2021 10:31 am

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 : 6
join : Sun Apr 03 , 2022 6:06 pm

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 : 1511
join : Sun Feb 14 , 2021 10:31 am

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 : 6
join : Sun Apr 03 , 2022 6:06 pm

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 : 1511
join : Sun Feb 14 , 2021 10:31 am

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 : 6
join : Sun Apr 03 , 2022 6:06 pm

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 : 1511
join : Sun Feb 14 , 2021 10:31 am

post

by solo »Mon Apr 04, 2022 10:26 pm

Please post as code the output of:

  • “cat /proc/sys/net/ipv4/ip_forward”
  • “brctl show”
  • ” ifconfig “
  • ” route -n “

solo

post : 1511
join : Sun Feb 14 , 2021 10:31 am

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 : 6
join : Sun Apr 03 , 2022 6:06 pm

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 : 1511
join : Sun Feb 14 , 2021 10:31 am

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.