PfSense openVPN not assigning default gateway to clients
-
I recently configured an openVPN server on pfSense to connect to my internal network using tunnelblick. The connection is established, and the server assigns a correct ip address to the client, but there is no change in the default gateway of the client, so everything else on the local network is unreachable. Please let me know if any more information than what is in the config files below is necessary to discover the issue.
openVPN config file:
dev ovpns1
verb 3
dev-type tap
dev-node /dev/tap1
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 SHA1
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
local 128.151.18.205
tls-server
server-bridge 192.168.42.36 255.255.224.0 192.168.40.10 192.168.40.49
client-config-dir /var/etc/openvpn-csc
tls-verify "/usr/local/sbin/ovpn_auth_verify tls 'Server' 1 "
lport 443
management /var/etc/openvpn/server1.sock unix
push "route 192.168.0.0 255.255.0.0"
push "redirect-gateway def1"
ca /var/etc/openvpn/server1.ca
cert /var/etc/openvpn/server1.cert
key /var/etc/openvpn/server1.key
dh /etc/dh-parameters.1024
tls-auth /var/etc/openvpn/server1.tls-auth 0client config file:
client
dev tap
proto tcp
remote 128.151.18.205 443
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert Mac.crt
key Mac.key
ns-cert-type server
tls-auth ta.key 1
cipher AES-128-CBC
auth SHA1
redirect-gateway def1 -
why TAP?
https://community.openvpn.net/openvpn/wiki/BridgingAndRoutingalso, do you bridge your dhcp of your lan?
-
why TAP?
https://community.openvpn.net/openvpn/wiki/BridgingAndRoutingalso, do you bridge your dhcp of your lan?
I am using TAP because my network configuration would allow traffic to the rest of the network from connected clients, but there would be no way for the traffic to route back because of security configurations.
I have a bridge set up on my network between the openVPN interface, and the LAN interface on the pfSense server.
-
"I have a bridge set up on my network between the openVPN interface, and the LAN interface on the pfSense server."
Gawd what a cluster!!!
You sure do not need tap to allow openvpn clients to connect to your lan network.. And what security concerns? You give your openvpn clients a connection on your openvpn network say 10.0.8.0/24 This is common openvpn network, or 10.0.200/24 then setup your firewall rules how you want to allow/block traffic between these clients and your network behind pfsense.
Routing back to them would be automatic if your normal lan clients are using pfsense as your gateway. What security concerns would their be?? And how is putting them on your lan network directly not more of security issue? If you put them on their own segment then you now easy to understand and maintain firewall (psense) between these segments that you can create what ever rules you want in.
-
I am using TAP because my network configuration would allow traffic to the rest of the network from connected clients, but there would be no way for the traffic to route back because of security configurations.
To be honest… this statement doesn't make any sense. Please re-phrase the issue you're trying to resolve by choosing a bridged solution over a routed one. The ONLY reason to use TAP is to connect to an application that relies on broadcast traffic. Routed is more efficient, routed scales better, etc, etc.
I have a bridge set up on my network between the openVPN interface, and the LAN interface on the pfSense server.
Do yourself a favor… remove the bridge and switch to routed. You will save yourself dozens of hours beating your head against the wall on this.
-
3 most common sources of pfSense troubles:
- Squid and related proxy junk
- bridging
- PEBKAC
::) ::) ::)
-
3 most common sources of pfSense troubles:
- Squid and related proxy junk
- bridging
- PEBKAC
::) ::) ::)
/thread
