Score:1

Server isn't responding to pings routed via vpn

in flag

I've server and virtual machine on it. I'm hosting OpenVPN on this server. The virtual machine has two interfaces: ens18 - for public IP, ens19 - for an internal network. I'm trying to ping 10.2.0.3 (virtual machine ip on ens19) via VPN, but it's not responding. When I run tcpdump -i ens19 icmp on the virtual machine, its returning this:

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ens19, link-type EN10MB (Ethernet), capture size 262144 bytes
16:50:25.931910 IP 10.8.0.2 > 10.2.0.3: ICMP echo request, id 1, seq 80, length 40
16:50:29.381784 IP 10.8.0.2 > 10.2.0.3: ICMP echo request, id 1, seq 81, length 40

Ping output:

Pinging 10.2.0.3 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Machine tcpdump output:

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
15:58:15.007090 IP 10.8.0.2 > 10.2.0.3: ICMP echo request, id 1, seq 45, length 40

My iptables rules:

Chain INPUT (policy ACCEPT 2806K packets, 1097M bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     all  --  eth0   any     anywhere             anywhere             state RELATED,ESTABLISHED
 198K   27M ACCEPT     udp  --  vmbr0  any     anywhere             anywhere             udp dpt:[my openvn port]
   40  2429 ACCEPT     all  --  tun0   any     anywhere             anywhere            
    0     0 ACCEPT     all  --  tun+   any     anywhere             anywhere            
    0     0 ACCEPT     all  --  tun+   any     anywhere             anywhere            

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
 197K   16M ACCEPT     all  --  tun0   vmbr0   anywhere             anywhere            
 177K  336M ACCEPT     all  --  vmbr0  tun0    anywhere             anywhere            
   45  2540 ACCEPT     all  --  tun0   any     10.8.0.0/24          10.2.0.3            
    2   104 ACCEPT     all  --  tun0   any     10.8.0.0/24          10.2.0.0/24         
    0     0 ACCEPT     all  --  tun+   any     anywhere             anywhere            

Chain OUTPUT (policy ACCEPT 3102K packets, 1303M bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     all  --  any    tun0    anywhere             anywhere       

My route table:

default via [my public ip] dev vmbr0 proto kernel onlink 
10.2.0.0/24 dev vmbr1 proto kernel scope link src 10.2.0.1 
10.8.0.0/24 dev tun0 proto kernel scope link src 10.8.0.1 
[my public ip] dev vmbr0 proto kernel scope link src [my gateway] 

Ip rule list:

0:      from all lookup local 
32766:  from all lookup main 
32767:  from all lookup default 

If you need some extra information, add a comment. Sorry for my bad English

Karthik avatar
cn flag
can you also edit the `tcpdump` command with complete command you used to capture the packets?
in flag
@Karthik on vpn machine: `tcpdump -i tun0 icmp` on virtual machine: `tcpdump -i ens19 icmp`
Karthik avatar
cn flag
thanks, just a quick guess, `rp_filter` can cause similar issues when we route traffic via tunnel. may be try disabling `rp_filter` and check the issue?
in flag
@Karthik i have to disable it on vpn machine or on virtual machine? and for what interface?
Karthik avatar
cn flag
Try disabling the rp_filter for the interface `ens19` in the virtual machine bearing `10.2.0.3`
in flag
@Karthik it was already disabled for all interfaces, but i enabled it for ens19, but still virtual machine isn't responding
Karthik avatar
cn flag
If you haven't, please try **disabling** `rp_filter` of `ens19` and check the issue. If it didn't resolve the issue, please try disable/enable the interface `ens19`.
in flag
@Karthik yes, I've disabled it, but nothing happens, disabling and enabling doesn't helps
Tom Yan avatar
in flag
Does the VM even have a route for `10.8.0.0/24` (via `10.2.0.1`)? Also please paste `iptables-save` instead. Also make sure you have a route that lead traffics for `10.2.0.0/24` to the tunnel on the VPN client (if you are not using a `redirect-gateway` / `0.0.0.0/0` route).
Karthik avatar
cn flag
Thanks @uQlel. Could you check if the ping response is disabled in kernel by `cat /proc/sys/net/ipv4/icmp_echo_ignore_all`?
in flag
@Karthik It returns 0. Ping works from ens18 as well, and ping works from vpn machine to virtual machine's ens19
in flag
@TomYan How to create this route? I'm newbie at networking
Tom Yan avatar
in flag
Run `ip r add 10.8.0.0/24 via 10.2.0.1` on the VM. For the VPN part, either add `route 10.2.0.0 255.255.255.0` to the client conf, or, add `push "route 10.2.0.0 255.255.255.0"` to the server conf, assuming you are using `client` / `pull` on the client conf. Note that these route are not *necessary* if both the VM(s) and the VPN clients use the server as their default gateway.
Tom Yan avatar
in flag
@uQlel Btw, what does `sysctl net.ipv4.ip_forward` return on the server?
Karthik avatar
cn flag
Also, could you run `tcpdump -ni any icmp host 10.8.0.2` and share the output? And please ping `10.2.0.3` from within the local machine.
in flag
@TomYan THX, it works!
Score:0
in flag

By @TomYan

Run ip r add 10.8.0.0/24 via 10.2.0.1 on the VM. For the VPN part, either add route 10.2.0.0 255.255.255.0 to the client conf, or, add push "route 10.2.0.0 255.255.255.0" to the server conf, assuming you are using client / pull on the client conf. Note that these route are not necessary if both the VM(s) and the VPN clients use the server as their default gateway

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.