@hr1sha Great 😄 that solved the issue, I am now getting the expected upload speed.
I guess that means I have been limited by the iPhone hardware (like also @Rico suspected).

I chose 256 encryption because I thought it is safer that 128, but after some quick research I guess 128 should be sufficiently safe (I guess).

@viragomann
thanks for help. I tried so many things and nothing works.
I solved it differently now. I connect direct to the client pfSense.
I solved it differently now.

@viragomann said in AWS OpenVpn routing issues after update.:

@swansense
I'm wondering, what is auto-updating there. This version is out of date for more than two years. You should consider to upgrade it.
However, I don't expect that an upgrade resolve your issue to be honest.

Which route does OpenVPN intend to add?
There should be a hint in the log. If not, maybe set a higher verbosity level.
Possibly the route is overlapping your local network.

Thank you.

You were correct changing the release branch and updating fixed my issue

@SteveITS

hey thanks Steve, will have a look at that too. Appreciate it!

@monkeh

0.1 millibit/sec?

Yeah, that is a tad slow. 😉

@philbio On the old desktop I installed the 2.7 version on today the CPU is a Intel Core i5-4570TE (2.7GHz) LGA1150, when I was doing a speed test the CPU guage in the gui never went above 10%

@harry63 Same issue here, have made several setting changes with no improvements.

@JKnott One other thing, it works fine with IPv6 over my LAN.

@viragomann

What would you like to know about them?

No vpn server subnat aint the default 192.168.1.0/24 or 192.168.0.0/24.

As often as humany possible.

With DCO mode on Plus you can use traditional routing because of the way it's hooked into the kernel. It works more like a regular interface there instead of only using OpenVPN's internal routing.

@johnpoz said in How to disable data encryption question.:

@pwood999 I would think if using ncp to neg the encryption, it would only need to be set on the server. I have never setup openvpn without encryption ;)

Server and clients all have to agree on a common cipher, so they all need to have 'none' chosen as the only option in the data cipher list and fallback cipher.

@Deadringers
As mentioned in your other thread, rules on the OpenVPN tab have priority over ones on the interface tab.
However, to get request packets on incoming traffic routed back properly, a pass rule on the interface tab must match the incoming traffic.

This means, you have either to remove all pass rules from the OpenVPN tab or modify them so that they do not match to the forwarded traffic.

The same is true for floating rules, if there are any applied to the VPN interface.

That sounds like a local network config issue on the target system. There are some cases where Windows will only accept inbound traffic from its own subnet unless it thinks it's on a certain type of network. Like if it's set to public vs private but maybe not exactly that.

If you need to fudge that you could setup a hybrid outbound NAT rule on the LAN to make the source of traffic appear to be the local network, but that can break or complicate certain protocols. It's best to fix the local network config on the client system.

I forked this off into a new thread so it would all be together since it's likely a different issue than the post it was on before.

If you are still having this problem on 2.7.0, please read through the following:

Most likely there is a configuration problem that has always been wrong but some change on the backend changed and now your previously "working" settings which happened to be incorrect in some way stopped working.

A few common things we have seen are:

SSL/TLS setups where people had filled in a tunnel network on the client when they should not SSL/TLS setups with a /24 tunnel network where the Client-Specific Overrides were not setup correctly breaking LAN-to-LAN routing Static Key configurations using the wrong subnet size for the tunnel network (e.g. /24 when it should have been /30) Not explicitly setting the same topology on both sides Some other routing conflict preventing the correct entries from being in the tables A configuration that worked by chance before that was never correct (e.g. routes in System > Routing instead of in OpenVPN natively) Policy routing rules overriding the VPN and sending the client traffic in some unexpected path Missing or incorrectly configured default gateway (e.g. set to auto when it should be set to a WAN or WAN failover group)

Compare your setup against the reference here: https://docs.netgate.com/pfsense/en/latest/recipes/openvpn-s2s-tls.html

There are a lot of troubleshooting suggestions for that sort of stuff at https://docs.netgate.com/pfsense/en/latest/troubleshooting/connectivity.html

But to boil that down a bit, you should check:

Look at the OS routing table on both sides, make sure there are entries for the default route and opposite side LAN(s) and that those routes are pointing to the correct OpenVPN interface(s). When you ping from the firewall make sure to ping from both the OpenVPN interface itself (default source) and again using the LAN interface as a source. That tests routing between the LANs in both directions, not just to/from the OpenVPN interface directly, which is a much different test. When pinging from a client on the LAN, look at its states under Diagnostics > States on both firewalls, there should be two entries on each, one as it enters the firewall and one as it exits the firewall. If something like outbound NAT is catching it, the NAT would show in these states. If the traffic is taking the wrong path, that would also show (e.g. it should go in LAN, out VPN, in VPN, out LAN). If the packets are exiting a WAN unexpectedly it may be from those clients hitting a policy routing firewall rule, so you might need to add a rule above whatever rule it's hitting to pass VPN traffic without a gateway set.

That should give you a better idea of what's going on and what needs fixed.

@matt84

I'd be happy to share my configs with the devs.

I have rolled back to 2.6 too.