Discussion:
[Openvpn-users] Cannot communicate with OpenVPN endpoint with TAP VPN
Riccardo Paolo Bestetti
2017-05-14 09:00:34 UTC
Permalink
Hello,
I'm trying to set up a "road warrior" VPN for my company.
We have a pfSense firewall (FreeBSD-based) which we use for all our VPN stuff.

The device is configured like so:
- 10.40.2.1/16 on the LAN interface
- IPsec tunnel VPN with remote network 192.168.40.100/24, with NAT 1:1 from 172.16.0.0/16 to 10.40.0.0/16 (this is with a SaaS company that won't change their setup unless strictly necessary)
- The OpenVPN configuration file at the end of this email
- Bridge between the LAN interface and the OpenVPN (ovpns1) interface

The issue is that everything can be reached from the "road warrior" clients normally, except for the firewall (10.40.2.1) and hosts over the IPsec VPN (which is the entire reason I'm using TAP instead of TUN: I need to keep the road warrior clients in the same network that can access the IPsec VPN).
The weird thing is that the firewall can be pinged and answers (but I suspect that's an OpenVPN thing), but I cannot reach its web configuration interface or connect with SSH. Please note that this is not a binding issue nor a firewall issue, the web interface binds on 0:443 and the firewall is temporarily set to allow everything to pass.
Right now I have a second "road warrior" VPN access, using IPsec, which works with the web interface but still doesn't work with the other IPsec VPN. I would like to use OpenVPN because IPsec looks pretty hackish to me, especially how it is implemented on pfSense/FreeBSD.

Best regards,
Riccardo Paolo Bestetti

---

OpenVPN configuration file:
dev ovpns1
verb 1
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 udp
cipher AES-256-CBC
auth SHA1
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
local [hidden IP address]
engine cryptodev
tls-server
mode server
client-cert-not-required
username-as-common-name
auth-user-pass-verify "/usr/local/sbin/ovpn_auth_verify [hidden script parameters]" via-env
tls-verify "/usr/local/sbin/ovpn_auth_verify tls 'server' 1"
lport 1194
management /var/etc/openvpn/server1.sock unix
max-clients 8
push "register-dns"
client-to-client
ca /var/etc/openvpn/server1.ca
cert /var/etc/openvpn/server1.cert
key /var/etc/openvpn/server1.key
dh /etc/dh-parameters.4096
tls-auth /var/etc/openvpn/server1.tls-auth 0
push "route-gateway 10.42.2.1"
push "route 10.42.0.0 255.255.0.0"
push "route 192.168.44.112 255.255.255.255"
Riccardo Paolo Bestetti
2017-05-14 09:59:05 UTC
Permalink
Hello,
Amending the configurations, the last three lies are:
push "route-gateway 10.40.2.1"
push "route 10.40.0.0 255.255.0.0"
push "route 192.168.40.112 255.255.255.255"

Best regards,
Riccardo Paolo Bestetti

On 14 May 2017, at 11:43 AM, Riccardo Paolo Bestetti <***@live.it<mailto:***@live.it>> wrote:

Hello,
I'm trying to set up a "road warrior" VPN for my company.
We have a pfSense firewall (FreeBSD-based) which we use for all our VPN stuff.

The device is configured like so:
- 10.40.2.1/16 on the LAN interface
- IPsec tunnel VPN with remote network 192.168.40.100/24, with NAT 1:1 from 172.16.0.0/16 to 10.40.0.0/16 (this is with a SaaS company that won't change their setup unless strictly necessary)
- The OpenVPN configuration file at the end of this email
- Bridge between the LAN interface and the OpenVPN (ovpns1) interface

The issue is that everything can be reached from the "road warrior" clients normally, except for the firewall (10.40.2.1) and hosts over the IPsec VPN (which is the entire reason I'm using TAP instead of TUN: I need to keep the road warrior clients in the same network that can access the IPsec VPN).
The weird thing is that the firewall can be pinged and answers (but I suspect that's an OpenVPN thing), but I cannot reach its web configuration interface or connect with SSH. Please note that this is not a binding issue nor a firewall issue, the web interface binds on 0:443 and the firewall is temporarily set to allow everything to pass.
Right now I have a second "road warrior" VPN access, using IPsec, which works with the web interface but still doesn't work with the other IPsec VPN. I would like to use OpenVPN because IPsec looks pretty hackish to me, especially how it is implemented on pfSense/FreeBSD.

Best regards,
Riccardo Paolo Bestetti

---

OpenVPN configuration file:
dev ovpns1
verb 1
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 udp
cipher AES-256-CBC
auth SHA1
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
local [hidden IP address]
engine cryptodev
tls-server
mode server
client-cert-not-required
username-as-common-name
auth-user-pass-verify "/usr/local/sbin/ovpn_auth_verify [hidden script parameters]" via-env
tls-verify "/usr/local/sbin/ovpn_auth_verify tls 'server' 1"
lport 1194
management /var/etc/openvpn/server1.sock unix
max-clients 8
push "register-dns"
client-to-client
ca /var/etc/openvpn/server1.ca<http://server1.ca>
cert /var/etc/openvpn/server1.cert
key /var/etc/openvpn/server1.key
dh /etc/dh-parameters.4096
tls-auth /var/etc/openvpn/server1.tls-auth 0
push "route-gateway 10.42.2.1"
push "route 10.42.0.0 255.255.0.0"
push "route 192.168.44.112 255.255.255.255"

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org<http://Slashdot.org>! http://sdm.link/slashdot
_______________________________________________
Openvpn-users mailing list
Openvpn-***@lists.sourceforge.net<mailto:Openvpn-***@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Loading...