Client Specific Override Always Assigns Network IP to Client



  • I have a tunnel network of 172.16.42.0/24 configured and a client specific override configured as 172.16.42.24/30.  When I connect my client gets an IP address of 172.16.42.24 which is the network IP.  It should be getting a .26 address from what I understand.

    It does this no matter what the override network is set to.  If I set it to 172.16.42.0/30 for example, it gives out the network IP in this case 172.16.42.0.

    What am I missing?



  • Are you sure you've got the CN entered correctly in the CSO?

    I've been bit a couple times by a leading/trailing space in the CN field and/or case sensitive entries.

    The other thing to watch if your experimenting is to make sure to take the server and client down completely to ensure all your changes are picked up.



  • @divsys:

    Are you sure you've got the CN entered correctly in the CSO?

    I've been bit a couple times by a leading/trailing space in the CN field and/or case sensitive entries.

    The other thing to watch if your experimenting is to make sure to take the server and client down completely to ensure all your changes are picked up.

    I don't see any errors in the CN.  I've also disconnected my client and restarted the OpenVPN service.  Still gets the same network IP address upon re-connection.  The weirdest thing of all though is that it's technically "working" as I'm connected and can access the resources I've created firewall rules for.  Something just isn't right about this though.


  • LAYER 8 Global Moderator

    "a client specific override configured as 172.16.42.24/30"

    How exactly are you assigning this?  Are you using /30 topology?  I Push a specific IP to my client via the overrides with

    ifconfig-push 10.0.8.100 255.255.255.0

    In the advanced box, where my tunnel network is 10.0.8.0/24 in the server settings.  I am not using /30 topology in my vpn settings.

    What pfsense are you using there was some changes to how /30 works and such in 2.3..



  • @johnpoz:

    "a client specific override configured as 172.16.42.24/30"

    How exactly are you assigning this?  Are you using /30 topology?  I Push a specific IP to my client via the overrides with

    ifconfig-push 10.0.8.100 255.255.255.0

    In the advanced box, where my tunnel network is 10.0.8.0/24 in the server settings.  I am not using /30 topology in my vpn settings.

    What pfsense are you using there was some changes to how /30 works and such in 2.3..

    On the latest 2.3.1.

    Server

    Client Override


  • LAYER 8 Global Moderator

    Not seeing any override?



  • That CSO isn't telling the server to assign a specific Tunnel IP at all, you need an "ifconfig-push" if you want to lock the client to a particular /30 IP.

    But your "push route 172.16.42.0 255.255.255.0" statement makes that moot anyway.
    On the one hand you're defining the tunnel as 172.16.42.0/30 (which would put the server at 172.16.42.1 not 172.16.42.24) and then you're telling the client how to reach the full 172.16.42.0/24 subnet.  You can't have it both ways  ;)

    What problem are you trying to solve with this?



  • Sorry for the confusion I changed the network to 172.16.42.0/30 after the .24/30 wasn't working.

    Forgetting the advanced options for a second (fixed the image), does the override not get created by simply defining the tunnel network of 172.16.42.0/30 in the CSO?  Shouldn't think give me an IP address of 172.16.42.2?



  • If everything from the Server to the Client and the CSO is set to 172.16.42.0/30 then definitely the Client should get 172.16.42.2 as an address.

    Is this a Peer-Peer SSL or a Remote Access server?

    As I mentioned before, the other thing to be careful of when making changes is to force a full restart of the server and client in that order.
    I've had to explicitly kill the Server process (without rebooting the box) to make sure it actually stops and restarts and picks up changes.
    Sometimes makes troubleshooting OpenVPN a bit of a pain (but worth it when it finall works).

    Post your full server and client configs and perhaps something will jump out.



  • @divsys:

    If everything from the Server to the Client and the CSO is set to 172.16.42.0/30 then definitely the Client should get 172.16.42.2 as an address.

    Is this a Peer-Peer SSL or a Remote Access server?

    As I mentioned before, the other thing to be careful of when making changes is to force a full restart of the server and client in that order.
    I've had to explicitly kill the Server process (without rebooting the box) to make sure it actually stops and restarts and picks up changes.
    Sometimes makes troubleshooting OpenVPN a bit of a pain (but worth it when it finall works).

    Post your full server and client configs and perhaps something will jump out.

    Remote Access Server.

    By full server/client configs you mean more than the images a few posts up?

    All I've done is restart the OpenVPN service and rebooted the client but I haven't tried explicitly killing any processes on my pfSense box or anything.

    I just don't get how I'm able to access resources being assigned this address…



  • Yah, the full screen shot has a few other sections (like Topology for one) that might affect things.

    The other things to try are a full reboot of the server box or (if that's too onerous) search for the running server process and explicitly kill it.
    Worth it just to make sure you're on a level playing field as far as previous attempts go.

    You can up the server's verbosity so you should be able to see if the CSO is getting applied when the client connects.
    Similarly the client logs may show what's trying to apply if you up the logging level.

    Are the clients just typical Win, android, iPhone, or something else?



  • @divsys:

    Yah, the full screen shot has a few other sections (like Topology for one) that might affect things.

    The other things to try are a full reboot of the server box or (if that's too onerous) search for the running server process and explicitly kill it.
    Worth it just to make sure you're on a level playing field as far as previous attempts go.

    You can up the server's verbosity so you should be able to see if the CSO is getting applied when the client connects.
    Similarly the client logs may show what's trying to apply if you up the logging level.

    Are the clients just typical Win, android, iPhone, or something else?

    Attached SS's of the Server and CSO's.  When I get home later I can troubleshoot further.  And yes the client I'm testing with is android phone.





Log in to reply