Problem with OpenVPN clients and routing?
-
"I've done which indicated high MTU sped up encrypt/decrypt"
What?? Where did you read such a thing?
Some time ago I came across an article on some testing done on high throughput openvpn. I think this may have been it. https://community.openvpn.net/openvpn/wiki/Gigabit_Networks_Linux
-
"For a LAN-based setup this can work, but when handling various types of remote users (road warriors, cable modem users, etc) this is not always a possibility. "
So this is a LAN based setup?
-
"For a LAN-based setup this can work, but when handling various types of remote users (road warriors, cable modem users, etc) this is not always a possibility. "
So this is a LAN based setup?
no, but in the testing I've done I have seen some small improvement in performance with that setting.
Anyway, this is getting off topic. As I've tried to reiterate, this setting I've used for quite some time. It doesn't cause the problem nor does its removal fix the problem.
-
src 127.0.0.1 doesn't seem right.. Shouldn't the source be the be Your IP on this side of the tunnel..
-
src 127.0.0.1 doesn't seem right.. Shouldn't the source be the be Your IP on this side of the tunnel..
That is from the command line of the firewall which has a NAT rule to access all VPN tunnels. This should simulate what gateway monitoring does, right?
The NAT outbound rules allow the firewall, 127.0.0.0/8, out to each VPN interface.
Just for testing purposes I made all those NAT rules as "this firewall" out to each interface, instead of 127.0.0.0/8
The same problem persists.
As soon as I even enable the gateway (system_gateways.php) of another openvpn client (I didn't even start the tunnel), I'm suddenly unable to ping the other side of the VPN tunnel that's already up.
ovpnc1: flags=8051 <up,pointopoint,running,multicast>metric 0 mtu 20000 options=80000 <linkstate>inet6 fe80::dacb:8aff:fe70:1374%ovpnc1 prefixlen 64 scopeid 0x7 inet 10.30.0.13 --> 10.30.0.1 netmask 0xffff0000 nd6 options=21 <performnud,auto_linklocal>groups: tun openvpn Opened by PID 86920 [2.4.0-BETA][removed]/root: ping 10.30.0.1 PING 10.30.0.1 (10.30.0.1): 56 data bytes 64 bytes from 10.30.0.1: icmp_seq=0 ttl=64 time=21.782 ms 64 bytes from 10.30.0.1: icmp_seq=1 ttl=64 time=21.251 ms ^C --- 10.30.0.1 ping statistics --- 2 packets transmitted, 2 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 21.251/21.517/21.782/0.266 ms [2.4.0-BETA][removed]/root: ping 10.30.0.1 PING 10.30.0.1 (10.30.0.1): 56 data bytes 36 bytes from localhost (127.0.0.1): Time to live exceeded Vr HL TOS Len ID Flg off TTL Pro cks Src Dst 4 5 00 0054 781b 0 0000 01 01 0000 127.0.0.1 10.30.0.1 36 bytes from localhost (127.0.0.1): Time to live exceeded Vr HL TOS Len ID Flg off TTL Pro cks Src Dst 4 5 00 0054 631d 0 0000 01 01 0000 127.0.0.1 10.30.0.1</performnud,auto_linklocal></linkstate></up,pointopoint,running,multicast> -
I went back to 2.3.4p1 and I have no more problems. Also please remember I didn't have problems for several days on 2.4. One of the 2.4 updates broke things. I hope it can be found and fixed.
-
You're the only person I've seen or heard of having trouble with multiple clients on 2.4 (or 2.3 for that matter).
I run several OpenVPN clients on 2.4 and they all work, 24/7, for weeks/months at a time.
It's something specific to your settings, either what you have configured or what is being pushed to you. It could be a conflicting or overlapping route or tunnel network, for example.
-
You're the only person I've seen or heard of having trouble with multiple clients on 2.4 (or 2.3 for that matter).
I run several OpenVPN clients on 2.4 and they all work, 24/7, for weeks/months at a time.
It's something specific to your settings, either what you have configured or what is being pushed to you. It could be a conflicting or overlapping route or tunnel network, for example.
I tried to show in an earlier post that the routes don't overlap. I don't specify remote networks in the OVPN client config either. I do have OVPN clients set to not pull routes and to not add/remove routes. That was how I was taught to do it and it works in pfsense 2.3. But, maybe that doesn't work with pfsense 2.4 or openvpn 2.4?
I'm not sure how it's logical for anybody to say it's on my end when I change nothing and it stops working after an update.
-
Because nobody else can reproduce it and it affects only you, the logical conclusion is that it is something in your environment, config, etc.
-
Because nobody else can reproduce it and it affects only you, the logical conclusion is that it is something in your environment, config, etc.
What you're implying is that my pfsense config can be magically changed, not by me, so as to cause a problem. That wouldn't be good business for netgate or for any users of pfsense. Nor does it make sense for software developers who usually pride themselves on logic.
I understand it's difficult to see this as a problem if only 1 person is reporting it but let's try to remember the facts of the case.
-
Until the actual cause is located, however, the burden is still on you to diagnose it because nobody else can. I'm not saying your config magically changed, but something about it is causing the unintended behavior.
OpenVPN 2.4 also does a lot more dynamic negotiation, like NCP, where new settings are used in potentially unexpected ways depending on what the other side does.
So it may be that the provider(s) are sending you settings that do nothing in 2.3.x but activate things in 2.4.x which could be part of your issue.
There have not been any changes in OpenVPN code on pfSense in over a month, and the most recent change to OpenVPN itself was nearly two months ago (OpenVPN 2.4.3 on June 21).
-
Little more info.
As I'm using 2.3.4p1 now I see that when an openvpn client is stopped the routes (as seen in diag_routes.php) are removed as they should be. In 2.4 betas they were not removed.
