Nope not fixed when its not on wifi as in local it does not use the DNS.

Ah! I guess I am getting it now.

I thought the public IP (185.220.xxx.xxx) that the server provides me is enough for the server to communicte with me and that the Virtual IP and Gateway IP are something purely local to me and I can set it myself. I now understand that these IPs are something that the VPN Server hands out to its clients and is the way for the server to communicate with the client (and back). Is this right?

So it absolutely does not make sense that I set it and expect that the server will "find me". I noticed that, after I setup the routing table, Virtual IP and Gateway IP with the above steps, data was going out into the tunnel but never coming back. This explains why the gateway was down.

What I am trying to do, as I mentioned in my initial post, is to prevent duplicate Gateway IPs when I connect to different servers (of the same provider). As of now, after a pfSense restart, I connect and disconnect the VPN clients with the duplicated IPs and after 2-3 tries it gets an IP from a different subnet. I guess I will have to live with this workaround.

@viragomann said in Gateway IP for openVPN gets duplicated:

To prevent get pushed the route from the server, check "Don't pull routes".
Then enter the network you want to route over the VPN into the "Remote network(s)" box.
However, I'm not sure what you really want to route here.

I see that I can only stop pulling the routes that the server pushes . I thought this option prevents setting the Virtual IP and Gateway IP and therefore thought this option isn't working for me and tried the pull-filter ignores where it appeared as if it is working for me.

With my newly, self-learnt background of networking, I was trying out stuff expecting it to work. Thanks for explaining the fundamentals to me.

On the other hand, I did see some discussions where it was mentioned that the duplicated Gateway IPs should not be an issue for pfSense loadbalancing as it does not do it with IPs and does not use the routing table. Is this true?

@khuram said in OpenVPN - Only works for a single user at a time.:

Also have you had any trouble with removing routes after a user is disconnected?

With this workaround in place, the routes appear to not be removed. Eg. after I just received a .211 address, I see:

x.x.x.208/29 x.x.x.177 UGS igb0.8 x.x.x.209 link#21 UHS lo0 x.x.x.210 link#21 UH ovpns3 x.x.x.211 ovpns3 UH ovpns3 x.x.x.216/29 x.x.x.177 UGS igb0.8 x.x.x.217 link#22 UHS lo0 x.x.x.218 link#22 UH ovpns1

That does not seem to create an issue for us.

hi, thanks só much for help, i was trying create without create vlan first and i realy don't know wy it doesn't worked. So, I create a vlan separated and did the same configuration as before using just WAN and it works, little bit slow but works, thanks

Ok, perfect.

@davebu said in PHP crashing - OpenVPN services down:

i.e. its a 'newbie' issue.

I guess you nail that one also asap.

@bbiketa said in OpenVPN strange disconnects:

I think it's OpenVPN server that's making problems, since other ovpn servers work fine and everyone

Compare the OpenVPN server settings directly with each other :
It lives here /var/etc/openvpn/ - and probably called : server1.conf.

@nirmalts the monitor ip is the VPN_WAN gateway of each VPN client but when I didn't check "Don't pull routes" I was suffering packet-loss.

VPN2_WAN without the "Don't pull routes" RTT is 8.1ms and I use it as the default route (0.0.0.0), using it for dns over vpn with the internal vpn dns ip.

@striker-pl said in Why am I seeing OpenVPN twice?:

Interesting. I don't see it listed under "Interface Groups".

No, it's not displayed there. However, it is an interface group.

So also consider that rules on the OpenVPN tab are applied as well if any and the group rules have priority over these on the interface tab according to the Firewall Rule Processing Order.

Just another quick funny thing that's happening ... now when I connect to the tun server on 1194, I get a stream of "packet rejected" messages from 1195. It still works though.

I just tried your suggestions and I'm still having the same issue with getting traffic to go through PIA. To troubleshoot I stopped the VPN service from running, set up the NAT rules and then started the service after enabling forwarding under DNS resolver. No luck was had on my end.

@jontabaco

dont know why but the supposed fix only worked for one day and nothing ive tried has resolved my remote ip from showing

The documentation seems to be pointing out that it doesnt really matter if it is chosen or not openVPN will automatically detect AES-NI and use it, if available, right?

Nothing needs selected for OpenVPN to utilize AES-NI. The OpenSSL engine has its own code for handling AES-NI that works well without using the BSD Cryptodev Engine.

https://docs.netgate.com/pfsense/en/latest/hardware/cryptographic-accelerator-support.html

Ok, found another post on Google that pointed out the issue. Had to choose Remote SSL and note Site To Site...

My next question: How can I advertise Client’s LAN to the server? So I can ping devices from the server-side.

According this this website, I need to add this to the servers config:

https://medium.com/@bjammal/site-to-site-vpn-on-a-single-host-using-openvpn-e9c5cdb22f92

cd /etc/openvpn
mkdir ccd
cd ccd
touch client
echo “iroute 192.168.40.128 255.255.255.248” > client

client-config-dir ccd
route 192.168.40.128 255.255.255.248

@johnpoz

I really don't know why some companies do certain things and sometimes I wonder if they do. 😉 However, as I said, Rogers is not alone in this, but it is a good idea. I recall people I know complaining how their ADSL address would change, right in the middle of them doing something. I get the impression some ISPs are nasty.

I discovered this feature at least 15 years ago. Of course, when I change hardware, I have to update the DNS alias. I'm not certain what will happen with my IPv6 host names, as I haven't changed any hardware in the 4 years I've been getting IPv6 from my ISP. I'm assuming the DUID will keep the prefix from changing.

Hi!

Issue was resolved now. OpenVPN Client Export package 1.4.23 has been release:
ae8f39e5-de52-4ae0-8fb4-0754b45b0e8d-image.png

Already updated on my pfSense box. UDP4 no more, its just UDP now:

34b392dc-632e-4220-8b03-1667d9a4b54d-image.png

Thank you so much to those who work-out the fix on this bug.
Cheers!

OK, I see the logic. Thanks.

Yeah that is just gibberish..