OpenVPN site to site - Only traffic from pfsense boxes work
-
@iago-op
Seems to be well.Static public IPs should better be hidden when you post a screenshot in the web. The PPPoE may change, but I don't know of the other one.
Interestingly the client show no use of the route. Maybe if you try a connection from the clients LAN.
Yes, absolutely weird.
We had already issues with VPNs that won't work while all seems fine. After pulling it down and start from scratch it mostly worked.You may try more investigations with the packet capture tool, but I cannot think of any further reason.
Only one thing are the firewall rules on OpenVPN interface. You didn't post a screenshot. So consider for pinging you have to allow ICMP or any protocol. If you have only TCP, ping will not work.
-
@viragomann said in OpenVPN site to site - Only traffic from pfsense boxes work:
@iago-op
Seems to be well.Static public IPs should better be hidden when you post a screenshot in the web. The PPPoE may change, but I don't know of the other one.
Interestingly the client show no use of the route. Maybe if you try a connection from the clients LAN.
Yes, absolutely weird.
We had already issues with VPNs that won't work while all seems fine. After pulling it down and start from scratch it mostly worked.You may try more investigations with the packet capture tool, but I cannot think of any further reason.
Only one thing are the firewall rules on OpenVPN interface. You didn't post a screenshot. So consider for pinging you have to allow ICMP or any protocol. If you have only TCP, ping will not work.
Yep, Thanks for the remainder of the public ips :)
the OpenVPN firewall rules are allow all for all protocols. I just make sure because of this tests specifically with ping.
There is any way to debug this kind of problems? Like a traceroute which indicates what interfaces goes through a packet?
Tank you again mate
-
@iago-op said in OpenVPN site to site - Only traffic from pfsense boxes work:
@viragomann said in OpenVPN site to site - Only traffic from pfsense boxes work:
@iago-op
Seems to be well.Static public IPs should better be hidden when you post a screenshot in the web. The PPPoE may change, but I don't know of the other one.
Interestingly the client show no use of the route. Maybe if you try a connection from the clients LAN.
Yes, absolutely weird.
We had already issues with VPNs that won't work while all seems fine. After pulling it down and start from scratch it mostly worked.You may try more investigations with the packet capture tool, but I cannot think of any further reason.
Only one thing are the firewall rules on OpenVPN interface. You didn't post a screenshot. So consider for pinging you have to allow ICMP or any protocol. If you have only TCP, ping will not work.
Yep, Thanks for the remainder of the public ips :)
the OpenVPN firewall rules are allow all for all protocols. I just make sure because of this tests specifically with ping.
There is any way to debug this kind of problems? Like a traceroute which indicates what interfaces goes through a packet?
Tank you again mate
I think I have a clue. Revieweing the logs for each interface I found that it's using ipv6 routing in the client side. While on the client side, openVPN is configured only to use ipv4
Maybe cloud be this ?
-
The routing protocol setting is at the bottom, you can check IPv4 gateway only there.
-
@viragomann said in OpenVPN site to site - Only traffic from pfsense boxes work:
The routing protocol setting is at the bottom, you can check IPv4 gateway only there.
In one side was ipv4 but in the other side was both. I changed to ipv4 only but this not fixed the problem.
as I'm expected.I keep investigating. If I do a packet capture on the openvpn interface in the client while a ping is in course, it does not register any packet.
-
@iago-op said in OpenVPN site to site - Only traffic from pfsense boxes work:
There is any way to debug this kind of problems? Like a traceroute which indicates what interfaces goes through a packet?
As mentioned, you can do some packet capture on the both pfSense boxes.
The VPN connection is like a network wire into the other site. Each site has a virtual interface. Here you can sniff the traffic.So for instance you try to ping from a clients LAN device to one on the remote site, you can trace the ping packets with packet capture on all the involved interface: clients LAN and OpenVPN, servers OpenVPN and LAN. So you can check where it stops.
But I don't understand what your first ping attempt show. It works from client to the servers LAN IP whith default, which means the source is the client OpenVPN IP. But it doesn't work if the source is the clients LAN IP, even if there is the correct route on the server for that subnet.
Your routing tables screens seem to be incomplete, but I guess, there will not be another route overlapping the clients LAN. -
@viragomann said in OpenVPN site to site - Only traffic from pfsense boxes work:
@iago-op said in OpenVPN site to site - Only traffic from pfsense boxes work:
There is any way to debug this kind of problems? Like a traceroute which indicates what interfaces goes through a packet?
As mentioned, you can do some packet capture on the both pfSense boxes.
The VPN connection is like a network wire into the other site. Each site has a virtual interface. Here you can sniff the traffic.So for instance you try to ping from a clients LAN device to one on the remote site, you can trace the ping packets with packet capture on all the involved interface: clients LAN and OpenVPN, servers OpenVPN and LAN. So you can check where it stops.
But I don't understand what your first ping attempt show. It works from client to the servers LAN IP whith default, which means the source is the client OpenVPN IP. But it doesn't work if the source is the clients LAN IP, even if there is the correct route on the server for that subnet.
Your routing tables screens seem to be incomplete, but I guess, there will not be another route overlapping the clients LAN.I've made some testing today, and I found that I can ping from my local client computers to the OpenVPN gateway on the other end. (and in the same end too)
Lets say I'm in the side of pfsense box 2 (10.0.50.1) with my IP: 10.0.50.10.
This end of the tunnel gets IP 10.0.18.2 (10.0.18.1 for the other end)I can ping both of these openvpn interfaces no problem from the local machine
But cannot ping the remote LAN computers (10.0.111.0/24)So there is a problem routing between openvpn interface 10.0.18.2 and the LAN network 10.0.111.0/24
But I cannot find the reason why this happens. The routing table looks good, there is an entry for this subnet in it:
And the firewall rules for the LAN allow incoming traffic from 10.0.18.0/24 and 10.0.50.0/24:
Should I consider reporting a bug for this issue? There is any public board to fill in a bug report?
Thank you @viragomann , you were very helpful :)
-
@iago-op
One thing I noticed. You are talking about a site-to-site VPN, but you have a /24 tunnel network.
A s2s should have a /30. So there is only one IP for the server and one for the client. I'd suggest to change this. -
@viragomann said in OpenVPN site to site - Only traffic from pfsense boxes work:
@iago-op
One thing I noticed. You are talking about a site-to-site VPN, but you have a /24 tunnel network.
A s2s should have a /30. So there is only one IP for the server and one for the client. I'd suggest to change this.Thanks mate for the tip.
Unfortunately, the problem persists. I can ping the remote end of the tunnel endpoint but cannot ping the LAN behind it.
It's driving me nuts. I've tested an IPSEC tunnel and works fine. I'm going to give-up this openvpn efort. Maybe I can help reporting this issue to the pfsense develoepers... I don't know
-
I finally get it to work!!
It was a problem with a configuration of an IPSec tunnel that I had previously on one end.
It turns out that although it was disabled, it has configured the subnet 10.0.18.0/24
So I assume that this configuration is not supported and having the same subnet on these different services could cause the issue.
Thanks @viragomann for your help :) I really appreciate mate