PfSense as client with Softether VPN server dont work, seems routing problems



  • Hi Guys.

    I am using softether on a VPS elsewhere and a PfSense 2.1.4 release 16.
    I am using the pfsense as tun client agains the softether and it connects, give a virtual ip from the server and everything is fine. But my pfsense is a gateway for a lan and i want to use this vpn as "gateway" to connect to reach another clients connected to sofether vpn.

    The strange is, from the pfsense after i connect using the ping tool i can ping the vpn clients on the softether network but from my lan no.
    I followed this tutorial https://forum.pfsense.org/index.php?topic=76015.0 and in ym case it is non working, well it is working but it is not doing routing.

    To make the things more strange, after i configured the interface for the openvpn client connection, i lost connectivity between the openvpn server running on the pfsense and the lan, i configured the rules but it seems doesnt work.

    A little schema:

    RoadWarrior–------------->PFSENSEOpenVPN Server (subnet 192.168.50.0/24)
    ---------------------Lost connection between interface OpenVPN and LAN-------------------
    LAN (192.168.10.0/24)--->PFSENSE---->WAN
                                                        ----->OpenVPN as Client (10.10.30.0/24)---->Lan 10.10.20.0/24 (gw 10.10.30.254)
                                                                                                                    ---->Lan 10.10.40.0/24 (gw 10.10.30.254)

    The connection between the lan and the lans .20 and .30 is not possible, but from the pfsense it is possible.

    My firewall rules:

    Interface LAN

    Interface VPN Client

    Interface OpenVPN

    Hope someone can help me :)



  • I guess the upstream OpenVPN server at 10.10.30.254 is pushing routes for 10.10.20.0/24 and 10.10.40.0/24 to the pfSense OpenVPN client. That is how pfSense knows to route there.

    On LAN you have the rule straight after anti-lockout that is policy-routing (=forcing) all traffic to gateway WAN_DHCP. So even though the pfSense routing table knows how to get to 10.10.20.0/24 and 10.10.40.0/24, the policy-routing rule is overriding that.

    Since the routing table seems to have all the necessary routing information, you should not need to specify a gateway in any rules. Try removing "WAN_DHCP" from that rule - it might all just work.

    If it turns out to be needed, you can assign an interface for that uplink-VPN and it will get a gateway. You can put rules before the "Allow all on LAN" rule, and make those rules pass source LANnet destination 10.10.20.0/24 and 10.10.40.0/24, gateway uplink-VPN-GW. That will force that traffic into that VPN.



  • Hi.

    I tried what you did but it seems doesnt work, if i try to run a traceroute to one of the hosts of this networks, it ends using the default gateway instead the openvpn client
    I tried to remove every route-pushing from the softether side to prevent route pushing and it doesnt work.
    After i connect using "tun", i got this in the logs.

    
    Dec 14 17:12:27	openvpn[8498]: Initialization Sequence Completed
    Dec 14 17:12:27	openvpn[8498]: ERROR: FreeBSD route add command failed: external program exited with error status: 1
    Dec 14 17:12:27	openvpn[8498]: /sbin/route add -net 10.10.20.0 10.10.30.254 255.255.255.0
    Dec 14 17:12:27	openvpn[8498]: ERROR: FreeBSD route add command failed: external program exited with error status: 1
    Dec 14 17:12:27	openvpn[8498]: /sbin/route add -net 10.10.40.0 10.10.30.254 255.255.255.0
    Dec 14 17:12:27	openvpn[8498]: /sbin/route add -net 10.10.40.0 10.10.30.18 255.255.255.0
    Dec 14 17:12:27	openvpn[8498]: /sbin/route add -net 10.10.20.0 10.10.30.18 255.255.255.0
    Dec 14 17:12:27	openvpn[8498]: /sbin/route add -net 10.10.30.0 10.10.30.18 255.255.255.0
    Dec 14 17:12:27	openvpn[8498]: /sbin/route add -net 128.0.0.0 10.10.30.18 128.0.0.0
    Dec 14 17:12:27	openvpn[8498]: /sbin/route add -net 0.0.0.0 10.10.30.18 128.0.0.0
    Dec 14 17:12:27	openvpn[8498]: /sbin/route add -net 178.62.Sani.Tized. 192.168.178.1 255.255.255.255
    Dec 14 17:12:27	openvpn[8498]: /usr/local/sbin/ovpn-linkup ovpnc3 1500 1557 10.10.30.17 10.10.30.18 init
    Dec 14 17:12:27	openvpn[8498]: /sbin/ifconfig ovpnc3 10.10.30.17 10.10.30.18 mtu 1500 netmask 255.255.255.255 up
    Dec 14 17:12:27	openvpn[8498]: do_ifconfig, tt->ipv6=1, tt->did_ifconfig_ipv6_setup=0
    Dec 14 17:12:27	openvpn[8498]: TUN/TAP device /dev/tun3 opened
    Dec 14 17:12:27	openvpn[8498]: TUN/TAP device ovpnc3 exists previously, keep at program end
    Dec 14 17:12:27	openvpn[8498]: ROUTE_GATEWAY 192.168.178.1
    Dec 14 17:12:27	openvpn[8498]: OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
    Dec 14 17:12:27	openvpn[8498]: OPTIONS IMPORT: route-related options modified
    Dec 14 17:12:27	openvpn[8498]: OPTIONS IMPORT: route options modified
    Dec 14 17:12:27	openvpn[8498]: OPTIONS IMPORT: --ifconfig/up options modified
    Dec 14 17:12:27	openvpn[8498]: OPTIONS IMPORT: timers and/or timeouts modified
    Dec 14 17:12:27	openvpn[8498]: PUSH: Received control message: 'PUSH_REPLY,ping 3,ping-restart 10,ifconfig 10.10.30.17           10.10.30.18,dhcp-option DNS 10.10.30.1,dhcp-option DNS 8.8.8.8,route-gateway 10.10.30.18,redirect-gateway def1'
    
    

    Even when i added this to the pfsense client a advanced options:

    
    auth-user-pass /home/nico/auth-file.txt;
    verb 5;
    route 10.10.40.0 255.255.255.0 10.10.30.254;
    route 10.10.20.0 255.255.255.0 10.10.30.254;
    route-gateway 10.10.30.1;
    
    

    and in "IPV4 Remote Network/s"

    
    10.10.30.0/24,10.10.20.0/24,10.10.40.0/24
    
    

    If i run a ifconfig on the pfsense, i seems an interface is ready with the ip address of the network

    
    ovpnc3: flags=8051 <up,pointopoint,running,multicast>metric 0 mtu 1500
    	options=80000 <linkstate>inet6 fe80::204:23ff:feaf:3046%ovpnc3 prefixlen 64 scopeid 0xd 
    	inet 10.10.30.13 --> 10.10.30.14 netmask 0xffffffff 
    	nd6 options=1 <performnud>Opened by PID 90627</performnud></linkstate></up,pointopoint,running,multicast> 
    

    But i can not run a ping using this interface.

    
    [2.1.4-RELEASE][admin@fw01.local]/root(4): ping -I ovpnc3 8.8.8.8
    ping: invalid multicast interface: `ovpnc3'
    
    

    What i am doing wrong?



  • Internally the 10.10.30.0/24 tunnel subnet gets divided up by the server, among the clients. So actually your client does not really get 10.10.30.254/24 as its other end - it is getting:

    /sbin/ifconfig ovpnc3 10.10.30.17 10.10.30.18 mtu 1500 netmask 255.255.255.255 up
    

    10.10.30.18 is the other end, and the various routes are being set to point to that.

    Those extra lines of yours:

    route 10.10.40.0 255.255.255.0 10.10.30.254;
    route 10.10.20.0 255.255.255.0 10.10.30.254;
    

    are making those messages:

    ERROR: FreeBSD route add command failed: external program exited with error status: 1
    

    and I imagine this won't help anything either:

    route-gateway 10.10.30.1;
    

    If you remove that stuff, and restart it all, what do you get in Diagnostics->Routes?
    Are there reasonable-looking routes pointing to the ovpn link?

    And post what you have for rules now - maybe there is just some rule out of order?



  • Hi Phil.

    If i deactivate the routes and restart the service, i got that on the openvpn logs:

    
    Dec 15 00:10:15	openvpn[35433]: Initialization Sequence Completed
    Dec 15 00:10:15	openvpn[35433]: ERROR: FreeBSD route add command failed: external program exited with error status: 1
    Dec 15 00:10:15	openvpn[35433]: /sbin/route add -net 10.10.40.0 10.10.30.18 255.255.255.0
    Dec 15 00:10:15	openvpn[35433]: ERROR: FreeBSD route add command failed: external program exited with error status: 1
    Dec 15 00:10:15	openvpn[35433]: /sbin/route add -net 10.10.20.0 10.10.30.18 255.255.255.0
    Dec 15 00:10:15	openvpn[35433]: /sbin/route add -net 10.10.40.0 10.10.30.18 255.255.255.0
    Dec 15 00:10:15	openvpn[35433]: /sbin/route add -net 10.10.20.0 10.10.30.18 255.255.255.0
    Dec 15 00:10:15	openvpn[35433]: /sbin/route add -net 10.10.30.0 10.10.30.18 255.255.255.0
    Dec 15 00:10:15	openvpn[35433]: /sbin/route add -net 128.0.0.0 10.10.30.18 128.0.0.0
    Dec 15 00:10:15	openvpn[35433]: /sbin/route add -net 0.0.0.0 10.10.30.18 128.0.0.0
    Dec 15 00:10:15	openvpn[35433]: /sbin/route add -net 178.62.sani.tized 192.168.178.1 255.255.255.255
    Dec 15 00:10:15	openvpn[35433]: /usr/local/sbin/ovpn-linkup ovpnc3 1500 1557 10.10.30.17 10.10.30.18 init
    Dec 15 00:10:15	openvpn[35433]: /sbin/ifconfig ovpnc3 10.10.30.17 10.10.30.18 mtu 1500 netmask 255.255.255.255 up
    Dec 15 00:10:15	openvpn[35433]: do_ifconfig, tt->ipv6=1, tt->did_ifconfig_ipv6_setup=0
    Dec 15 00:10:15	openvpn[35433]: TUN/TAP device /dev/tun3 opened
    Dec 15 00:10:15	openvpn[35433]: TUN/TAP device ovpnc3 exists previously, keep at program end
    Dec 15 00:10:15	openvpn[35433]: ROUTE_GATEWAY 192.168.178.1
    Dec 15 00:10:15	openvpn[35433]: OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
    Dec 15 00:10:15	openvpn[35433]: OPTIONS IMPORT: route-related options modified
    Dec 15 00:10:15	openvpn[35433]: OPTIONS IMPORT: route options modified
    Dec 15 00:10:15	openvpn[35433]: OPTIONS IMPORT: --ifconfig/up options modified
    Dec 15 00:10:15	openvpn[35433]: OPTIONS IMPORT: timers and/or timeouts modified
    Dec 15 00:10:15	openvpn[35433]: PUSH: Received control message: 'PUSH_REPLY,ping 3,ping-restart 10,ifconfig 10.10.30.17 10.10.30.18,dhcp-option DNS 10.10.30.1,dhcp-option DNS 8.8.8.8,route-gateway 10.10.30.18,redirect-gateway def1,route 10.10.20.0 255.255.255.0 vpn_gateway,route 10.10.40.0 255.255.255.0 vpn_gateway'
    Dec 15 00:10:14	openvpn[35433]: SENT CONTROL [vpn.sanitized.co]: 'PUSH_REQUEST' (status=1)
    
    

    Again, pings now from the interface assigned as gateway to the vpnclient works (VPNESA) and even a ping from the LAN to the ip assigned by the openvpn client, in that case 10.10.30.17, which is the LAN side of the vpn connections, works.
    It seems something is not routing from or just the ack from the other side (but if it works to another LAN connected to this gw, like 10.10.40.254, it should be the same for the 10.10.30.254 (.254 are the gw between networks or virtual hubs that name Softether linked using a L3 Virtual switch)

    Rules of LAN

    
    *	*	*	LAN Address	80 22	*	*	 	Anti-Lockout Rule	
    IPv4 *	*	*	10.10.20.0/24	*	VPNESA	none	 	VPN-NODE-ROUTE-01 	
    IPv4 *	*	*	10.10.30.0/24	*	VPNESA	none	 	VPN-NODE-ROUTE-02 	
    IPv4 *	*	*	10.10.40.0/24	*	VPNESA	none	 	VPN-NODE-ROUTE-03 	
    IPv4 *	LAN net	*	*	*	*	none	 	Default allow LAN to any rule 
    
    

    Rules of Interface VPNNODE01

    
    IPv4 *	VPNNODE01 net	*	*	*	*	none	 
    
    

    Rules of OpenVPN

    
    IPv4 *	*	*	10.10.20.0/24	*	VPNESA	none	 	route vpn -> office	
    IPv4 *	*	*	10.10.30.0/24	*	VPNESA	none	 	route vpn -> esavpn 	
    IPv4 *	*	*	10.10.40.0/24	*	VPNESA	none	 	route vpn -> minions 	
    IPv4 *	*	*	*	*	*	none	 	OpenVPN VPN Office wizard 
    
    

    My routes:

    
    0.0.0.0/1	10.10.30.18	UGS	0	11888	1500	ovpnc3	=>
    default	192.168.178.1	UGS	0	7406358	1500	vr0	 
    8.8.4.4	192.168.178.1	UGHS	0	2295	1500	vr0	 
    8.8.8.8	192.168.178.1	UGHS	0	99483	1500	vr0	 
    10.10.20.0/24	10.10.30.18	UGS	0	0	1500	ovpnc3	 
    10.10.30.0/24	10.10.30.18	UGS	0	1147	1500	ovpnc3	 
    10.10.30.17	link#13	UHS	0	0	16384	lo0	 
    10.10.30.18	link#13	UH	0	1	1500	ovpnc3	 
    10.10.40.0/24	10.10.30.18	UGS	0	1749	1500	ovpnc3	 
    127.0.0.1	link#4	UH	0	25801	16384	lo0	 
    128.0.0.0/1	10.10.30.18	UGS	0	14784	1500	ovpnc3	 
    178.62.210.204	192.168.178.1	UGHS	0	300347	1500	vr0	=>
    178.62.210.204/32	192.168.178.1	UGS	0	0	1500	vr0	 
    192.168.10.0/24	link#10	U	0	49491838	1500	bridge0	 
    192.168.10.1	link#10	UHS	0	0	16384	lo0	 
    192.168.50.0/24	192.168.50.2	UGS	0	3695	1500	ovpns1	 
    192.168.50.1	link#11	UHS	0	0	16384	lo0	 
    192.168.50.2	link#11	UH	0	15	1500	ovpns1	 
    192.168.150.0/24	192.168.150.2	UGS	0	0	1500	ovpns2	 
    192.168.150.1	link#12	UHS	0	0	16384	lo0	 
    192.168.150.2	link#12	UH	0	0	1500	ovpns2	 
    192.168.178.0/24	link#3	U	0	1643	1500	vr0	 
    192.168.178.1	00:e0:c5:4e:7a:79	UHS	0	11603	1500	vr0	 
    192.168.178.22	link#3	UHS	0	0	16384	lo0	 
    208.67.220.220	192.168.178.1	UGHS	0	3038	1500	vr0	 
    208.67.222.222	10.10.30.18	UGHS	0	3226	1500	ovpnc3	 
    
    

    I am totally lost, any ideas? maybe PfSense is corrupted?



  • It seems something is not routing from or just the ack from the other side (but if it works to another LAN connected to this gw, like 10.10.40.254, it should be the same for the 10.10.30.254 (.254 are the gw between networks or virtual hubs that name Softether linked using a L3 Virtual switch)

    So you can reach 10.10.40.254 OK?
    and 10.10.20.254?

    10.10.30.254 is in the tunnel - I do not expect you can ping that, the OpenVPN server at the other end is just giving your pfSense client 10.10.30.17 to 10.10.30.18



  • Hi, I'm very interested in to this. Anyone could make this work ? thanks



  • PsySkeletor, did you get this to work?  If so, can you post a description on your configs, I can't get the pfsense client to connect to my softether server - my configs are off.