No ... and yes. Using the GUI : no solution but click click click. Not using the GUI : You are the limiting factor of possibilities. First : Create one or two users manually. Do a config export, Diagnostics > Backup & Restore >Backup & Restore Consider exporting OpenVPN (server users) only. Yo wind up having an xml file with the correct format. Now, you can script as much as you want. You only have to respect the XML format. Import the file. Check for results. edit : if you are using certs as an identification, things will get a little bit more complicated, but the principal stays the same.

Shouldn't the Gateway at least reply when you "monitor ip" for the OVPN Servers' tunnel address? [image: 1589496101112-gatewaysstatus.jpg]

For reasons I had to kill and reinstall the server and the problem is back. If I connect from an external address, pf does not set the connection as 'Established' and kills it after ~30 seconds. Also weird: If I disable pf completely (pfctl -d), the connections is established and remains stable, so it's definitively pf that`s killing my connections. But since I can't leave the server with pf disabled, that's not an option. I've tried a few other tricks, like disabling TX Checksum Offload (https://xcp-ng.org/docs/guides.html#pfsense-vm), settings in the firewall, but couldn't find anything. Has any one else seen something like this?

@kevindd992002 No.

No, I was talking about that maybe ip address "52.4.131.46" not beeing the right one for the website, for "https://rilm.org" So i've setup the things like u've said, and after that i've got no internet access, which is a good thing, but it also cuts access to "https://rilm.org", which is a bad thing. The only thing working in browser, going somewhere, is "52.4.131.46", and it reaches that nginx test page that I was talking about. So, it looks more like a DNS problem now. The DNS's entered here in options are Google's public ones. I've also tried push "route 192.168.1.0 255.255.255.0" in Advanced Config, to no avail.

@Jxck Well, it certainly won't work, without it being configured on the VPN.

Glad you have it working now. Adjust your Client Firewall and turn it back on. -Rico

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