OpenVPN "Allow communication between clients" fail



  • Hi all, (sorry for bad english)

    i was using pfsense 1.2.3 since month and finally switch to 2.0 Beta.

    WOW, good job for a BETA guys !!  ;D

    but here the 2 problem i face from a week with openvpn

    1rst : i've set up a openvpn server like the sticky post "OpenVPN for Remote User : A How to"

    everything is well explain ant the basic function of the VPN work except for a thing, vpn client are unable tp ping or see each other. :(

    vpn client can easyly ping host on LAN, WLAN and vice-versa.

    i've checked the option "Allow communication between clients connected to this server", save, reestablish conneciton from client but nothing. ping does'nt work (firewall rules are set to allow all and windows firewall disabled) :-\

    2nd : it seem that the openvpn dhcp server does'nt respect de mask given in CIDR

    i've set "Tunnel Network" to "10.0.0.0/24" (255.255.255.0) but client still having 10.0.0.0/30 (255.255.255.252) ip adress  ???

    i've set for a test "Tunnel Network" to "10.0.0.0/30" but client were unable to connect after that !  :-\

    does somebody faced the same problems or have a solution ?  ;)



  • Regarding the second issue: That is normal. If you check the routing table (or the OpenVPN client log) you'll see that OpenVPN adds routes for the subnet(s) you want your client to access.


  • Rebel Alliance Developer Netgate

    The clients could probably see and ping each other's OpenVPN IP addresses, which are assigned as /30's out of the /24 address pool.

    If you want the LAN addresses on each side to be accessible, you need a route statement for each side in the server's config, and an entry on the Client-Specific Config. tab for each client's Common Name, which contains a custom option iroute statement for their LAN subnets. Do a search for iroute on the doc wiki for more examples (see the link in my sig).



  • thanks for reply

    @Fr3d:

    Regarding the second issue: That is normal. If you check the routing table (or the OpenVPN client log) you'll see that OpenVPN adds routes for the subnet(s) you want your client to access.

    So if i understand well, the tunnel subnet is not the same as the client.
    So even if i put a /24 in the tunnel network, client will always have a /30 ?
    Is there any way to modify de subnet mask to put a /16 for tunnel and /24 for client ?

    @jimp:

    The clients could probably see and ping each other's OpenVPN IP addresses, which are assigned as /30's out of the /24 address pool.

    If you want the LAN addresses on each side to be accessible, you need a route statement for each side in the server's config, and an entry on the Client-Specific Config. tab for each client's Common Name, which contains a custom option iroute statement for their LAN subnets. Do a search for iroute on the doc wiki for more examples (see the link in my sig).

    My setup is probably not enough clear. It's not a site-to-site vpn. It's probably what we call a "road warrior" (but i'm not sure of the term) wich computer (such as client) connect to my PFSense box (such as server)

    OPENVPN is in Remote Access SSL/TLS mode. I have also put my local lan network in "Local Network" parameters wich is 172.16.0.0/16 so VPN client (wich are located in several different place)  are able to see LAN client and vice-versa BUT VPN client are not able to see other VPN client.

    Sorry if i was not enough clear.


  • Rebel Alliance Developer Netgate

    @corotte:

    My setup is probably not enough clear. It's not a site-to-site vpn. It's probably what we call a "road warrior" (but i'm not sure of the term) wich computer (such as client) connect to my PFSense box (such as server)

    OPENVPN is in Remote Access SSL/TLS mode. I have also put my local lan network in "Local Network" parameters wich is 172.16.0.0/16 so VPN client (wich are located in several different place)  are able to see LAN client and vice-versa BUT VPN client are not able to see other VPN client.

    Sorry if i was not enough clear.

    It was clear enough, I'm not sure you understood what I was trying to say, however.

    Say this is the layout (using some semi-random addresses):

    A is the server, it uses 192.168.0.x, with an address pool of 10.0.0.0/24
    B is a client, it uses 192.168.99.2
    C is a client, it uses 192.168.205.5

    When B connects, its OpenVPN interface is probably getting 10.0.0.6/30, with a gateway of 10.0.0.5
    When C connects, its OpenVPN interface is probably getting 10.0.0.10/30, with a gateway of 10.0.0.9

    The client-to-client option lets you ping and reach 10.0.0.6 from 10.0.0.10 and vice versa.

    If you want to reach the actual LAN IPs, such as 192.168.99.2 and 102.168.205.5, you need the route/iroute statements I mentioned before.

    There is no reason to assign bigger than a /30 to an OpenVPN client - these are just point-to-point connections. If you want more IPs, you can route whatever subnets you like to the clients selectively.



  • thanks for fast reply

    so, if i understand well, (and to be brief)
    the setup you are talking about is that the LAN subnet of the PFSense box (in my case 172.16.0.0/16) will be able to reach the openvpn client's network such as 192.168.100.0/24 or others ?


  • Rebel Alliance Developer Netgate

    It probably wouldn't route to the rest of the client's subnet, only to the LAN IP address of the client's machine.

    If you were connecting site-to-site with routers setup that way, it would let you reach the full subnets, but because of many other issues (routing, default gateway, etc, etc) it wouldn't be possible to route to a subnet via a PC running the OpenVPN client software – but it would at least let you reach the client PC's LAN IP.

    Alternately, you can just use whichever OpenVPN IP address they get to reach the other clients, you can hardcode those on the client, and set an option on the server to reflect that (Static IP, I believe) -- I haven't had to mess with doing that, so I'm not 100% sure on what syntax you'd need in the client config files, probably an ifconfig line.



  • @jimp:

    It probably wouldn't route to the rest of the client's subnet, only to the LAN IP address of the client's machine.

    If you were connecting site-to-site with routers setup that way, it would let you reach the full subnets, but because of many other issues (routing, default gateway, etc, etc) it wouldn't be possible to route to a subnet via a PC running the OpenVPN client software – but it would at least let you reach the client PC's LAN IP.

    Alternately, you can just use whichever OpenVPN IP address they get to reach the other clients, you can hardcode those on the client, and set an option on the server to reflect that (Static IP, I believe) -- I haven't had to mess with doing that, so I'm not 100% sure on what syntax you'd need in the client config files, probably an ifconfig line.

    ok, now i better understand (sorry for delayed reply)

    well, i'll probably have to change the complete setup because i want every openvpn client to be in the same network or subnet so they can see each other.

    Some advice or idea ?


  • Rebel Alliance Developer Netgate

    Why do you want them all in the same subnet? I wouldn't recommend doing it that way. The only thing you might gain is the ability to browse windows shares between sites, and that can be fixed to work in different subnets by putting a WINS server at the main site.

    To get everyone on the same subnet, you would likely need some kind of bridged OpenVPN setup but then the LAN IPs used by each side would need to be in the same subnet as well.

    You might be able to manually set the interface addresses on both sides (e.g. ifconfig line in the config) but it still doesn't really gain you much.



  • @jimp:

    Why do you want them all in the same subnet? I wouldn't recommend doing it that way. The only thing you might gain is the ability to browse windows shares between sites, and that can be fixed to work in different subnets by putting a WINS server at the main site.

    To get everyone on the same subnet, you would likely need some kind of bridged OpenVPN setup but then the LAN IPs used by each side would need to be in the same subnet as well.

    You might be able to manually set the interface addresses on both sides (e.g. ifconfig line in the config) but it still doesn't really gain you much.

    well, it's probably too hard to be setup for the use i want  ;D

    but there is a thing that seem unanswer :
    using the setup found in "OpenVPN for Remote User : A How to",
    why by checking option "Allow communication between clients connected to this server" openvpn client still not able to ping/see each other ?  ???

    i don't know but i'm probably completely missing something or this is a little bug  :-\


  • Rebel Alliance Developer Netgate

    Your clients can probably see each other, but not from the IP Addresses you are expecting.

    With two clients connected, find out what the IP address of their OpenVPN client interfaces are, not their respective LAN IP addresses.

    You can probably connect between those.



  • I have a same problem (clients connected can not see each other despite that option being checked).

    They do connect to the openvpn just fine (status shows all 4 clients (2 connected through WAN and 2 through LAN)). Firewalls on the clients are off (LAN ones as I'm testing with them for now). Even though I try and ping the correct IPs (as shown by the openvpn status) it still does not work. There is no contact between the clients.

    This used to work on 1.2.2 but then I upgraded to 1.2.3 and now to 2.0 beta and no go (both for 1.2.3 and for 2.0 beta). I've tried recreating the tunnel as well as using the old one that worked on 1.2.2 but no go. Clients just refuse to see each other.

    This is the client config file if it helps:

    
    client
    dev tun
    proto udp
    remote 192.168.1.1 1196
    
    resolv-retry infinite
    nobind
    
    persist-key
    persist-tun
    
    ca ca.crt
    cert xxx.crt
    key xxx.key
    
    ns-cert-type server
    cipher AES-256-CBC
    comp-lzo
    verb 3
    
    

    Anyway I just have no idea how to continue with this so if anyone has any advice it would be very appreciated.


Log in to reply