Connected to OpenVPN, but no network except for 1 IP Address
-
Gotcha. Just did that, and no luck still. I was assigned 192.168.2.3. I can ping myself, but not 192.168.2.1 or anything on 192.168.1.x network.
-
Please post the clients routing table.
-
Sorry for the delay on this -
https://imgur.com/a/8kJZjFW
I'm connected now via my phone with a 192.168.2.3 address but can't connect to anything. I have a desktop connected via 192.168.2.2 address which works fine.
-
That's the routing table from pfSense, the server, not from the client, who has trouble with accessing something.
-
Sorry for the delay on this. Here is a print out of the 192.168.2.3 address that connects to the VPN but doesn't work connecting to anything on the network:
https://imgur.com/a/LgLGRAE
-
The routes on the client seem to be fine.
Does each user login with a different user name and also certificate if the server is running in SSL/TLS mode?
What does the server log show when a second client is connecting?
-
Yeah, that's what is weird. Different user names. Client log shows it connects just fine and gets DHCP. I feel like it's a routing issue of some sort, but everything looks setup correctly.
-
Sounds stupid, but on my LAN interface, it's setup as 192.168.1.1/24. I'm not limiting myself at all am I ? That's just configuring the IP of the pfSense box, right?
-
For troubleshooting try to ping the LAN address 192.168.1.1.
This should work at least if the client routes are set correctly.
Then try to ping a LAN device. -
Not able to ping either when connected as the 2nd VPN client (1921.68.2.3)
-
So please post the clients IPv4 routing table.
-
Post your server1.conf (/var/etc/openvpn).
-
I posted the IPv4 routing table above earlier, and you stated that it looked fine?
Here is the server1.conf files:
dev ovpns1 verb 1 dev-type tun dev-node /dev/tun1 writepid /var/run/openvpn_server1.pid #user nobody #group nobody script-security 3 daemon keepalive 10 60 ping-timer-rem persist-tun persist-key proto tcp-server cipher AES-128-CBC auth SHA256 up /usr/local/sbin/ovpn-linkup down /usr/local/sbin/ovpn-linkdown client-connect /usr/local/sbin/openvpn.attributes.sh client-disconnect /usr/local/sbin/openvpn.attributes.sh multihome tls-server server 192.168.2.0 255.255.255.0 client-config-dir /var/etc/openvpn-csc/server1 username-as-common-name plugin /usr/local/lib/openvpn/plugins/openvpn-plugin-auth-script.so /usr/local/sbin/ovpn_auth_verify_async user TG9jYWwgRGF0YWJhc2U= false server1 1195 tls-verify "/usr/local/sbin/ovpn_auth_verify tls 'OpenVPN+Server+Certificate' 1" lport 1195 management /var/etc/openvpn/server1.sock unix push "route 192.168.2.0 255.255.255.0" push "route 192.168.1.0 255.255.255.0" push "dhcp-option DNS 8.8.8.8" push "dhcp-option DNS 4.4.4.4" duplicate-cn ca /var/etc/openvpn/server1.ca cert /var/etc/openvpn/server1.cert key /var/etc/openvpn/server1.key dh /etc/dh-parameters.2048 tls-auth /var/etc/openvpn/server1.tls-auth 0 ncp-ciphers AES-128-GCM persist-remote-ip float topology subnet ~ ~ ~ ~ ~ ~ ~ ~ -
A couple things I see:
- The tunnel network is being pushed out to your clients as a route to a remote network, which is incorrect. Remove "192.168.2.0/24" from the IPv4 Local network(s) line.
- Considering this is a routed, split-tunnel deployment, why push public DNS servers?
Another thing to watch out for is... in a routed solution, the LAN subnets have to be unique across both ends. So, in your situation, any client that's connecting from a LAN subnet of either 192.168.1.0/24 or 192.168.2.0/24 will break the routing to the tunnel.
On the server-side, ideally, you will want to move away from popular subnets used by common SOHO routers (192.168.1.0/24, 192.168.2.0/24, etc) on both the LAN and the tunnel network.
-
This post is deleted! -
@marvosa Thanks. I removed the DNS and removed the 192.168.2.0/24 from local network line. Connected again just fine on the client, but still can't connect to anything. The network I'm on right now is using a 10.x.x.x scheme. I'm pulling my hair out trying to figure out wtf the problem is.
-
Post new screenshots of both the client's routing table when connected and PFsense.
