After upgrade to 2.3 Client Specific Overrides wont work
-
If you are using net30 then each client gets a /30 and that's how it should work with overrides that have a tunnel network set to use /30 there (but the main server would still show something like a /24 for example).
If the server is set to /30 the override should be using the correct syntax. Did you edit/save the override after fixing the server setting?
-
Config diff with the relevant section as requested:
2.2 Config is gone too.@@ -3666,25 +3666,25 @@ <tunnel_networkv6><remote_network><remote_networkv6>- <gwredir>+ <local_network>192.168.130.0/24</local_network> <local_networkv6><maxclients><compression>adaptive</compression> - <passtos>+ <passtos></passtos> <client2client>yes</client2client> <dynamic_ip>yes</dynamic_ip> <pool_enable>yes</pool_enable> - <serverbridge_dhcp>+ <topology>net30</topology> + <serverbridge_interface>none</serverbridge_interface> <serverbridge_dhcp_start><serverbridge_dhcp_end>- <netbios_enable>+ <netbios_enable></netbios_enable> <netbios_ntype>0</netbios_ntype> <netbios_scope>- <no_tun_ipv6>+ <verbosity_level>1</verbosity_level> - <topology>subnet</topology></no_tun_ipv6></netbios_scope></netbios_enable></serverbridge_dhcp_end></serverbridge_dhcp_start></serverbridge_dhcp></passtos></maxclients></local_networkv6></gwredir></remote_networkv6></remote_network></tunnel_networkv6>
Altough i am absolutly sure that is was set to /30 before the upgrade. it seems that the topology was switched to subnet somehow.
even every override was set to a specific /30 inside the /24 openvpn network. and each host has a specific gateway and host ip assigned.Example:
Network: 10.246.195.12/30
Advanced: ifconfig push 10.246.195.14 10.246.195.13; -
Hmm, do you happen to have a copy of the config in the history from before the 2.3 upgrade to check a diff of that section? For example, select the older config and then one just after the upgrade, see what value was there on 2.2.x.
Also if you had to switch the topology, the CSC files probably all need resynced, so a reboot would do that, or Diag > Command, PHP exec:
require_once("openvpn.inc"); openvpn_resync_all();
I'm looking at a better automated fix for that for 2.3.1, but I'd like to get this issue nailed down first.
-
Nope sorry… no old config available.
But i do have the old installation media for the 2.2.6 and i'm setting up a little vm environment atm to check if i can reproduce that errorUpdate: Ok. VM is off limits atm...
Does the 2.3 Update affect both nanobsd slices at once? if not i can switch to the other slice and look into the old configPS: SSH Login is broken too... Putty error: expected key exchange group packet from server
-
The config is in /conf/, not one of the OS slices, and some older revisions are in in /conf/backup/, but only 5 since NanoBSD does not keep them. So if you didn't keep a config backup, it may be lost. I was just hoping to see what your config was to start with for OpenVPN so I could see how it ended up switching unexpectedly.
SSH isn't broken, but you might have to update your PuTTY config to accept a stronger cipher or key exchange (e.g. DH 14). Default PuTTY should work though, unless maybe it was a very old config that started it. Check under the session settings, connection, SSH, and then under Kex beneath that. Make sure it's set to SSH2. On my PuTTY config that works, Encryption cipher selection is set to "AES (SSH-2 only), Blowfish, 3DES", Kex is set to DH Group exchange, DH group 14, DH group 1, then RSA.
-
what i do have is a config (don't yell at me… it worked fine all the time so i had no need to make a config backup) from june 2014...
now comes the strange thing.
The OpenVPN server behaved as it was set to /30 mode.
BUT the topology_subnet tag is set to empty... don't know what it meant back then... but i think it was just a checkbox if it sould use the whole subnet or not<openvpn><openvpn-server><vpnid>1</vpnid> <mode>server_tls</mode> <protocol>UDP</protocol> <dev_mode>tun</dev_mode> <ipaddr><interface>wan</interface> <local_port>1194</local_port> <description><custom_options><caref>5303e959aac29</caref> <crlref>5303e9a03ad5c</crlref> <certref>5303e97c2736c</certref> <dh_length>1024</dh_length> <cert_depth>1</cert_depth> <crypto>AES-128-CBC</crypto> <engine>none</engine> <tunnel_network>10.246.195.0/24</tunnel_network> <tunnel_networkv6><remote_network><remote_networkv6><gwredir><local_network>192.168.130.0/24</local_network> <local_networkv6><maxclients><compression>yes</compression> <passtos><client2client>yes</client2client> <dynamic_ip>yes</dynamic_ip> <pool_enable>yes</pool_enable> <topology_subnet><serverbridge_dhcp><serverbridge_interface>none</serverbridge_interface> <serverbridge_dhcp_start><serverbridge_dhcp_end><netbios_enable><netbios_ntype>0</netbios_ntype></netbios_enable></serverbridge_dhcp_end></serverbridge_dhcp_start></serverbridge_dhcp></topology_subnet></passtos></maxclients></local_networkv6></gwredir></remote_networkv6></remote_network></tunnel_networkv6></custom_options></description></ipaddr></openvpn-server></openvpn>
–--- Update
Ok managed to get my fingers on a recent config diff with version change from 12 to 15
First Version: 4/11/16 08:13:52 12.0 407 KiB admin@192.168.131.2: Creating restore point before package installation.
Second Version: 4/13/16 12:38:28 15.0 403 KiB (system): Upgraded config version level from 12.0 to 15.0Altough the openvpn server is only particialy configured...
<openvpn><openvpn-server>@@ -1726,7 +1732,6 @@ <client2client><dynamic_ip>yes</dynamic_ip> <pool_enable>yes</pool_enable> - <topology_subnet><serverbridge_dhcp><serverbridge_interface>none</serverbridge_interface> <serverbridge_dhcp_start>@@ -1736,6 +1741,7 @@ <netbios_scope><no_tun_ipv6><verbosity_level>1</verbosity_level> + <topology>subnet</topology></no_tun_ipv6></netbios_scope></serverbridge_dhcp_start></serverbridge_dhcp></topology_subnet></client2client></openvpn-server> <openvpn-csc><custom_options>ifconfig push 192.168.254.246 192.168.254.245;</custom_options> @@ -1754,9 +1760,6 @@</openvpn-csc></openvpn>
-
I managed to get a config from another source and found the problem with the upgrade code. It was testing that value incorrectly.
Once you fix the value on the server and re-save the CSCs (or use that code I posted earlier, or reboot), everything should be OK.
-
I found also my old Config:
<openvpn><openvpn-server><vpnid>1</vpnid> <mode>server_tls_user</mode> <authmode>Local Database</authmode> <protocol>UDP</protocol> <dev_mode>tun</dev_mode> <ipaddr><interface>any</interface> <local_port>33119</local_port> <custom_options>route 192.168.201.0 255.255.255.0;route 192.168.202.0 255.255.255.0;</custom_options> <caref>561365821e077</caref> <crlref><certref>561367656e6cf</certref> <dh_length>4096</dh_length> <cert_depth>2</cert_depth> <strictusercn><crypto>AES-256-CBC</crypto> <digest>SHA512</digest> <engine>none</engine> <tunnel_network>192.168.200.0/24</tunnel_network> <tunnel_networkv6><remote_network><remote_networkv6><gwredir><local_network><local_networkv6><maxclients>15</maxclients> <compression>adaptive</compression> <passtos><client2client>yes</client2client> <dynamic_ip><pool_enable>yes</pool_enable> <topology_subnet><serverbridge_dhcp><serverbridge_interface>none</serverbridge_interface> <serverbridge_dhcp_start><serverbridge_dhcp_end><netbios_enable><netbios_ntype>0</netbios_ntype> <netbios_scope><no_tun_ipv6><verbosity_level>1</verbosity_level> <duplicate_cn></duplicate_cn></no_tun_ipv6></netbios_scope></netbios_enable></serverbridge_dhcp_end></serverbridge_dhcp_start></serverbridge_dhcp></topology_subnet></dynamic_ip></passtos></local_networkv6></local_network></gwredir></remote_networkv6></remote_network></tunnel_networkv6></strictusercn></crlref></ipaddr></openvpn-server> <openvpn-csc><custom_options>iroute 192.168.201.0 255.255.255.0</custom_options> <common_name>handyvpn</common_name> <block><tunnel_network>192.168.201.0/24</tunnel_network> <local_network>192.168.131.0/24,192.168.133.0/24,192.168.130.0/24</local_network> <local_networkv6><remote_network><remote_networkv6><gwredir><push_reset><netbios_enable><netbios_ntype>0</netbios_ntype></netbios_enable></push_reset></gwredir></remote_networkv6></remote_network></local_networkv6></block></openvpn-csc> <openvpn-csc><custom_options>iroute 192.168.202.0 255.255.255.0</custom_options> <common_name>workvpn</common_name> <block><tunnel_network>192.168.202.0/24</tunnel_network> <local_network>192.168.131.0/24,192.168.133.0/24,192.168.130.0/24,192.168.134.0/24</local_network> <local_networkv6><remote_network><remote_networkv6><gwredir><push_reset><netbios_enable><netbios_ntype>0</netbios_ntype></netbios_enable></push_reset></gwredir></remote_networkv6></remote_network></local_networkv6></block></openvpn-csc></openvpn>
Maybe it helps….
But anyways thanks for your work. -
yep got the error too…
default was to provide a /30 subnet to every client wich corresponds to <topology_subnet>in the config.
if you set it to only provide one single ip to a client it switches to <topology_subnet>yes</topology_subnet>reboot was not necessary... just had to switch the openvpn config back to net30 and restart the openvpn server. everything worked from then on</topology_subnet>
-
jimp., i tried the command below from both the server side the client side and I am still experiencing the same issue. Still end up ending putting the route command on the client side to the correct /30 gw ip.
require_once("openvpn.inc");
openvpn_resync_all(); -
jimp., i tried the command below from both the server side the client side and I am still experiencing the same issue. Still end up ending putting the route command on the client side to the correct /30 gw ip.
require_once("openvpn.inc");
openvpn_resync_all();Sorry if i'm repeating, thread is long and I've been answering dozens of them today.
Check the server, make sure it's on net30, check the client, make sure it's on net30 (if it's on 2.3, if it's on 2.2 there was no client option for that).
Check a CSO/CSC, make sure it's only got a value in the tunnel network, not ifconfig in the advanced options. Save on there to be certain it's fresh.
Check /var/openvpn-csc/server<id>/ <name>and make sure the ifconfig looks OK there
Edit and save the client to ensure it's interface is rebuilt, maybe even try rebooting the client.</name></id>
-
jimp, unless I am missing something, I don't see net30 on the PFS that is on the server side (under Servers and Client Specific Overrides tab). I only see the net30 on the PFS that on the client side in the Client tab.
-
Hi everyone,
My VPN server had subnet topology, not net30 before the upgrade and I also had some issues with the client specific overrides, the clients were receiving network ip addresses instead of the client ip addresses I've configured with ifconfig-push in the Advanced filed of openvpn-CSO.
I did follow jimps suggestion to check the /var/etc/openvpn-csc folder and I saw that the client config files generated there had two ifconfig-push commands in them.
The first was the proper one I configured and the second was an ifconfig-push with the network IP of the tunnel.Went back to the gui in the CSO, removed "Tunnel Network" setting on the clients and restarted the openvpn services. This fixed the issue and now all of my clients are receiving the ip addressess I've setup with ifconfig-push.
I am not sure if the issue was generated by me when I entered the "Tunnel Network" ip addressess long time ago, but in the previous version of pfSense it did not cause any issues.
I do have multiple pfSense boxes with OpenVPN and subnet topology so I checked one of the v.2.2.6 we use, and the client specific overrides worked just fine with both the "Tunnel Network" ip address and the ifconfig-push address in the Advanced field.
I tested the old v.2.2.6 pfSense client specific overrides without the "Tunnel Network" just with the ifconfig-push and the clients kept working just fine, so i updated those afterwards without any issues.
I don't know where I saw that the "Tunnel Network" should be set in the client specific overrides when using subnet topology, or if it was left from a time when we were using net30, but this was my experience and I hope this helps someone.
-
This is in the Remote Access Server settings.
![Screen Shot 2016-04-14 at 2.10.06 AM.png](/public/imported_attachments/1/Screen Shot 2016-04-14 at 2.10.06 AM.png)
![Screen Shot 2016-04-14 at 2.10.06 AM.png_thumb](/public/imported_attachments/1/Screen Shot 2016-04-14 at 2.10.06 AM.png_thumb) -
Derelict, I see it on the client setting side and not on the server setting side. This is more of an issue now that i see it on a PPOE connection. The manual route that i added tends to disappear when the PPOE disconnect and reconnect.
-
My issue is almost identical as nastov. Something in OPVN 2.3 has changed on the tunnel network settings that way it push the network gw to the clients.
I have the below in 2.2.6
PFS Hub side
Server Tab: IPv4 Tunnel Network: 10.9.9.0/24Client Specific Overrides Tab:
Client/Site A: Tunnel Network: 10.9.9.0/30
Client Site B: Tunnel Network: 10.9.9.4/30PFS Spoke siteA)
Client Tab: IPv4 Tunnel Network: 10.9.9.0/30PFS Spoke siteB)
Client Tab: IPv4 Tunnel Network: 10.9.9.4/30In this scenario, the server would push down the correct /30 gw to the sites (10.9.9.1 to Site A and 10.9.9.5 to site B) and work as expected
Now on the 2.3, it pushes GW of 10.9.9.1 to both site, leaving SITE A in working order and Site B broken.
I end up for doing for 2.3 below and all the PFS tunnel are in one big /24 and one common GW as opposed /30 with its own GW . Setting the typology to subnet and/or net30 does not seem to make a difference based on my observations.
Server (hub side)
Server Tab: IPv4 Tunnel Network: 10.9.9.0/24Client Specific Overrides Tab:
Client/Site A: Tunnel Network: <blank>Client Site B: Tunnel Network: <blank></blank></blank> -
Had the same issue, not a Topology (net30) issue. Just selected a VPN server for CSC override and disabled "Prevent this client from receiving any server-defined client settings." Was lucky enough that one CSC was working and the rest failing.
-
In conjunction with this topic i'm trying to figure out a similar issue with our Mgmt-OpenVPN network.
Reading the last topic update i'm wondering if anyone can point out if the syntax for the ifconfig-push has been changed since V2.3.x …
In both my 2.2.6 backup and my current 2.3.1 backup all my CSC's <advanced>entries are configured starting with:
<custom_options>ifconfig-push 10.150.0....Note the dash ( - ) between 'ifconfig' and 'push'!
In the last topic entry, the dash is gone (several times).... Should i change all my CSC's in this way?</custom_options></advanced>
-
Just wanted to fill in on this with the issues I experience.
I want my users to authenticate through LDAP, so I set Server Mode to "Remove Access (SSL/TLS + User Auth)", but then CSO stops working.
When I set Server mode to only "Remote Access (SSL/TLS)" without User Auth, CSO starts working again.
I see that the Topology setting have been mentioned a couple of times in the thread, but I run with topology = subnet so the problem exists regardless of what topology is set to.I don't know if this worked prior to 2.3.X.
I currently run pfsense 2.3.1-RELEASE-p5 (amd64) / FreeBSD 10.3-RELEASE-p3.
-
When you enable user auth, the server gets an option that treats the username as the common name. So your CSOs have to match the LDAP login usernames, not the CN of the certificate. But ideally those should both be identical.