OpenVPN TAP-Interface: No PING response

Started by h-net, December 28, 2018, 02:33:05 PM

Previous topic - Next topic
hello,

i have a established OpenVPN-TAP-Connection.
Server interface: ovpns2 10.0.8.1
Client interface: ovpnc1 10.0.8.2

if i ping to the ip-address of the client from the server side, the client does not respond.
if i ping to the ip-address of the server from the client side, the server does not respond.

but the output of  "tcpdump -i ovpnc1"(client) / "tcpdump -i ovpnc2"(server) shows that the ping is received by the other side.
for example, this message is received on both sides when the server pings the client:
14:09:23.934750 IP 10.0.8.1 >10.0.8.2: ICMP echo request, id 21924, seq 367, length 64

i thought that the firewall blocks something, so i made two floating-rules that allow all packages with the destination (second rule with source) of 10.0.8.0/24 with logging.
the package-live-filter-view shows me

Server-Side: OpenVPN-Interface | Dec 28 14:20:40  | 10.0.8.2 | 10.0.8.1 | icmp | USER_RULE: Allow 10.0.8.0/24 as Source
Client-Side: OpenVPN-Interface | Dec 28 14:20:40  | 10.0.8.2 | 10.0.8.1 | icmp | USER_RULE: Allow 10.0.8.0/24 as Destination

this shows that the packages are allowed by the firewall on both sides.
(the "bytes-received on the client side" / "sent on the server side" at the vpn-status-page are also increasing while pinging )

WHY DOES THE SERVER/CLIENT NOT RESPOND TO THE PING???
what can i do to figure this out?

thanks for your help
h-net

Hi,

never tried it before, but here same result for my fully functional tunnels. Maybe you need a NAT rule for the reply? I don't really see the use case for this ping pong ;-)

Ping the LAN IP of your sense on the the other end and it will work without any problem, I guess...
kind regards
chemlud
____
"The price of reliability is the pursuit of the utmost simplicity."
C.A.R. Hoare

felix eichhorns premium katzenfutter mit der extraportion energie

A router is not a switch - A router is not a switch - A router is not a switch - A rou....

From your use of tcpdump I'm going to assume your client is Unix of some variety.

Try this from the client: ping -I 10.0.8.2 10.0.8.1

If that works, then you have a routing issue in that neither end of the tunnel has a route for the network on the other side and ping uses an IP outside 10.0.8.0/24 as its source.

Bart...