Small NAT problem. (1way ping only) LAN-to-OPENVPN



  • Hello,

    I am having a little problem connecting site-to-site my PBX in my data center & my pfsense at home with openvpn.

    PBX (10.8.2.1) <====> (10.8.2.2) Pfsense at home <====> (192.168.7.0/24) LAN subnet.

    I have a small piece of voip equipment (192.168.7.8) that needs to connect the PBX,  in a layer2 , so that they can talk back & forward.

    Due to my IP situation (No public IP's at home) I opted for a static shared key setup, where the PBX at my data center is uring it's static IPv4 to provide an OPENVPN server, & my home pfsense is used as an OPENVPN client.

    So far, there is nothing magic,  my pfsense connects fine to the PBX, which has 10.8.2.1 on a tap01 interface, while my home pfsense is using 10.8.2.2.

    PINGS look good!!

    PBX (10.8.2.1) <====> (10.8.2.2) Pfsense at home <====> (192.168.7.0/24) LAN subnet.

    I added the proper routing scripts on the linux PBX box to see the LAN behind my pfsense:
    add route -net 192.168.7.0 netmask 255.255.255.0 gw 10.8.2.2

    I added firewall rules to allow traffic & now I have no problems getting PBX to see all lan machins.

    PING 192.168.7.7 =>  OK!!!  (from PBX 10.8.2.1)

    [root@h03 ~]# ping 192.168.7.7
    PING 192.168.7.7 (192.168.7.7) 56(84) bytes of data.
    64 bytes from 192.168.7.7: icmp_seq=1 ttl=249 time=68.6 ms
    64 bytes from 192.168.7.7: icmp_seq=2 ttl=249 time=90.4 ms
    64 bytes from 192.168.7.7: icmp_seq=3 ttl=249 time=66.1 ms
    64 bytes from 192.168.7.7: icmp_seq=4 ttl=249 time=66.3 ms
    64 bytes from 192.168.7.7: icmp_seq=5 ttl=249 time=66.0 ms
    64 bytes from 192.168.7.7: icmp_seq=6 ttl=249 time=66.2 ms
    ^C
    --- 192.168.7.7 ping statistics ---
    6 packets transmitted, 6 received, 0% packet loss, time 5454ms
    rtt min/avg/max/mdev = 66.031/70.649/90.470/8.914 ms
    [root@h03 ~]#
    
    

    PING 10.8.2.1 => OK!!!  (From my home pfsense)

    [2.1-RELEASE][root@fiber.localdomain]/root(3): ping 10.8.2.1
    PING 10.8.2.1 (10.8.2.1): 56 data bytes
    64 bytes from 10.8.2.1: icmp_seq=0 ttl=64 time=243.459 ms
    64 bytes from 10.8.2.1: icmp_seq=1 ttl=64 time=64.693 ms
    64 bytes from 10.8.2.1: icmp_seq=2 ttl=64 time=64.843 ms
    64 bytes from 10.8.2.1: icmp_seq=3 ttl=64 time=95.660 ms
    64 bytes from 10.8.2.1: icmp_seq=4 ttl=64 time=65.630 ms
    ^C
    --- 10.8.2.1 ping statistics ---
    5 packets transmitted, 5 packets received, 0.0% packet loss
    round-trip min/avg/max/stddev = 64.693/106.857/243.459/69.323 ms
    
    

    However when i ping 10.8.2.1 from any LAN machine, i got no response…   
    I tired playing with my outbound NAT without luck, ... any help?

    C:\Users\User>ping 10.8.2.1
    
    Pinging 10.8.2.1 with 32 bytes of data:
    Request timed out.
    Request timed out.
    Request timed out.
    Request timed out.
    
    Ping statistics for 10.8.2.1:
        Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
    
    C:\Users\User>
    

    Here is my openvpn server configurations:

    OPENVPN SERVER:

    dev tap
    ifconfig 10.8.2.1 255.255.255.0
    secret static.key
    proto tcp-server
    port 1195
    keepalive 10 60
    ping-timer-rem
    persist-tun
    persist-key
    comp-lzo
    auth none
    cipher BF-CBC
    up /etc/openvpn/up.sh
    down /etc/openvpn/down.sh
    push "route 192.168.7.0 255.255.255.0"
    push "route-gateway 10.8.2.1"
    
    

    UP script

    route add -net 192.168.7.0 netmask 255.255.255.0 gw 10.8.2.2
    
    

    DOWN Script
    UP script

    route del -net 192.168.7.0 netmask 255.255.255.0 gw 10.8.2.2
    
    

    OPENVPN CLIENT CONFIG:

    
    Server Mode: peer to peer (shared key)
    Protocol: TCP
    Device mode: tap	
    Interface: GW Group1 
    Local port	:  (left blank)
    Server host or address:  x.x.x.x  (ip address of PBX)	
    Server port: 1195	
    Proxy host or address: (left blank)	
    Proxy port: (left blank)
    Proxy authentication extra options: (left blank)
    Authentication method : none
    Server host name resolution:  (checked) Infinitely resolve server
    IPv4 Tunnel Network: 10.8.2.0/24
    IPv4 Remote Network/s: 10.8.2.0/24
    Compression	(Checked) Compress tunnel packets using the LZO algorithm.
    
    Advanced:
    ifconfig 10.8.2.2 255.255.255.0;
    keepalive 10 60;
    ping-timer-rem;
    persist-tun;
    persist-key;
    auth none;
    route 10.8.2.0 255.255.255.0;
    route 192.168.7.0 255.255.255.0;
    
    

    Any clue why pfsense 192.168.7.1/24-10.8.2.2/24  can ping 10.8.2.1, & my LAN cannot?  I thought the "Automatic outbound NAT rule generation (IPsec passthrough included)" would make it work automatically …. i tried manually adding this outbound manual rule with no luck:

    OpenVPN  192.168.7.0/24 *	10.8.2.0/24 * 192.168.7.0/24	 * NO
    

    Any idea why this is not working?



  • Do you have rules on LAN that would be blocking (=not passing) the traffic to 10.8.2.1?
    And it should work without any NAT rules, because pfSense and the PBX device know routes to all the subnets concerned.



  • not that I am aware of.

    however i am a newbie to pfsense, & I've been doing openvpn for a long time, just not with pfsense & I've put already 8h of attempts last night without success.

    Clarification:  I use two internet connections, a vsat & a low latency DSL, & use traffic shaper & gateway groups to seperate my voip traffic.  All voip traffic going to PBX's, including openvpn must not go go via VSAT, but via the gw group "voip"  I did this by adding all my voip servers IP's to an ALIAS, & prevented those aliases by talking to the VSAT  gateway group "visat tier1, DSL tier2"
    "voip gw group" has DSL as tier1, & VSAT as tier2, just to keep things working in case of faliure.

    I've attached a screenshot of my gateway, LAN rules

    & here are my openvpn logs as well:

    Dec 12 13:15:58	openvpn[91233]: OpenVPN ROUTE: OpenVPN needs a gateway parameter for a --route option and no default was specified by either --route-gateway or --ifconfig options
    Dec 12 13:15:58	openvpn[91233]: OpenVPN ROUTE: failed to parse/resolve route for host/network: 10.8.2.0
    Dec 12 13:15:58	openvpn[91233]: OpenVPN ROUTE: OpenVPN needs a gateway parameter for a --route option and no default was specified by either --route-gateway or --ifconfig options
    Dec 12 13:15:58	openvpn[91233]: OpenVPN ROUTE: failed to parse/resolve route for host/network: 10.8.2.0
    Dec 12 13:15:58	openvpn[91233]: OpenVPN ROUTE: OpenVPN needs a gateway parameter for a --route option and no default was specified by either --route-gateway or --ifconfig options
    Dec 12 13:15:58	openvpn[91233]: OpenVPN ROUTE: failed to parse/resolve route for host/network: 192.168.7.0
    

    I am kind of clueless on why it won't allow my LAN to talk with 10.8.2.1…  I've done this before on another pfsense box for a friend, and it worked like a charm!!  hehhe :)
    Thanks  phil.davis,  I apreciate any insight or help.










  • hmm, strange!!
    this NAT problem still eludes me.

    Why doesn't pfsense route traffic from LAN to OPENVPN?? The fact is that pfsense itself can ping & reach the OPENVPN server, & that the vpnserver is even able to ping the lan clients no problems…

    maybe it is in these logs...  what could it be?  ::)

    I'm willing give this problem a quick $50 via paypal  for whoever that can spare me another white night like yesterday  ;)
    P.M please if anyone is interested to help.




  • I think the 1st LAN rule after the Anti-Lockout rule is the problem. It feeds any traffic from LANnet to anywhere but the voip alias, into "day" gateway group. I think that is going to force packets for 10.8.2.1 into the "day" gateway group, which goes out some WAN connection and into the public internet - but you want those packets to go onto the OpenVPN link and stay "private".
    The 3rd-last rule - LANnet to 10.8.2.0/24 needs to be above it, then the traffic to 10.8.2.1 will get passed to the normal routing table and be routed as required across the OpenVPN.
    The last 2 rules look like you trying things to see if they will work - 2nd-last is backwards, last is effectively the same as 3rd-last - they can both be deleted to clean things up.
    Hope it works - fingers crossed  ;)



  • That's it!!

    it worked like a charm, just moving the rule above that 1st one did the trick…  traffic is now going both way like a charm!

    Thank you so much.

    is there anything i can do to show my appreciation?




  • I am a volunteer working with INF in Nepal - buy a Christmas gift for someone from our catalog at http://secure.inf.org/gifts/usd/  :)


Log in to reply