4. Pfsense - OpenVPN - Pfsense - no traffic

Pfsense - OpenVPN - Pfsense - no traffic

  • K

    Hello…great forum lots of excellent information here.  I am finally ready to ask for some help so please be gentle...

    My setup:

    Main office:
    Pfsense 2.0.3
    Lan: xxx.xxx.10.0/25
    Wan: xxx.xxx.11.2/29 static
    DMZ: xxx.xxx.64.0/24

    New office:
    Pfsense 2.0.3
    Lan: xxx.xxx.10.128/25
    Wan: xxx.xxx.11.5/29 static

    Configured OpenVPN Tunnel but no traffic is passing

    Some hints as to what I should be looking at or possible issues that would cause this.  I already have an Any / Any rule on OpenVPN.

    Thank you in advance!

    0
  • M

    Welcome to the forums!

    Need more info, but first of all, there's no reason to mask Reserved addresses as they are internal and can not be routed over the internet :)

    1.  Post your server1.conf and client1.conf.
    2.  Post the firewall rules from the openvpn tab (on both sides).
    3.  Does the tunnel even come up?

    0
  • K

    OK, I've made some progress.

    Tunnel is up
    Traffic is passing both ways and I can ping and use resources from either side…this is good!

    My only issue now is that I cannot access our DMZ 192.168.64.x/24 from the remote side.  I put a "route push" to the DMZ into the open VPN server config but that still does not work.

    DMZ rules: Any/Any

    I know it's got to be an easy one....just missing something!

    0
  • M

    Probably firewall related, but could be routing….  hard to tell without seeing what you have configured.  Post info requested please.

    0
  • K

    Server1.conf is for remote access from home.

    Here are the conf from the VPN Tunnel.

    server2.conf:

    dev ovpns2
    dev-type tun
    dev-node /dev/tun2
    writepid /var/run/openvpn_server2.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
    up /usr/local/sbin/ovpn-linkup
    down /usr/local/sbin/ovpn-linkdown
    local xxx.xxx.11.2
    ifconfig 192.168.80.1 192.168.80.2
    lport 1195
    management /var/etc/openvpn/server2.sock unix
    push "route xxx.xxx.10.0 255.255.255.128"
    route xxx.xxx.10.128 255.255.255.128
    secret /var/etc/openvpn/server2.secret
    push route "xxx.xxx.10.0 255.255.255.248"
    push route "192.168.64.0 255.255.255.0"

    Client1.conf:

    dev ovpnc1
    dev-type tun
    dev-node /dev/tun1
    writepid /var/run/openvpn_client1.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
    up /usr/local/sbin/ovpn-linkup
    down /usr/local/sbin/ovpn-linkdown
    local xxx.xxx.11.5
    lport 1195
    management /var/etc/openvpn/client1.sock unix
    remote xxx.xxx.11.2 1195
    ifconfig 192.168.80.2 192.168.80.1
    route xxx.xxx.10.0 255.255.255.128
    secret /var/etc/openvpn/client1.secret

    OpenVPN Rules are ANY/ANY allowed.

    0
  • M

    you can leave the local and remote statements masked as they are public, but you can unmask your push route and route statements… since they are reserved addresses.  We need to see them if we're going troubleshoot effectively.

    I see some possible issues, but need those ranges unmasked.

    Also, can you communicate with your DMZ from the LAN on server-side?

    0
  • P
     

    push "route xxx.xxx.10.0 255.255.255.128"
route xxx.xxx.10.128 255.255.255.128
secret /var/etc/openvpn/server2.secret
push route "xxx.xxx.10.0 255.255.255.248"
push route "192.168.64.0 255.255.255.0"

    The 2nd (middle) push route is certainly not needed - it is a subnet of the 1st (top) one.
    I think the correct syntax is:

    push "route 192.168.64.0 255.255.255.0"

    The 1st (top) one has the correct syntax, the others have the quote in the wrong place.
    Maybe it is as simple as that?
    Otherwise post firewall rules also.

    0
  • K

    Ok, here is the modified server1.conf:

    dev ovpns2
    dev-type tun
    dev-node /dev/tun2
    writepid /var/run/openvpn_server2.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
    up /usr/local/sbin/ovpn-linkup
    down /usr/local/sbin/ovpn-linkdown
    local xxx.xxx.11.2
    ifconfig 192.168.80.1 192.168.80.2
    lport 1195
    management /var/etc/openvpn/server2.sock unix
    push "route 170.198.10.0 255.255.255.128"
    route 170.198.10.128 255.255.255.128
    secret /var/etc/openvpn/server2.secret
    push "route 192.168.64.0 255.255.255.0"

    Client1.conf:

    dev ovpnc1
    dev-type tun
    dev-node /dev/tun1
    writepid /var/run/openvpn_client1.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
    up /usr/local/sbin/ovpn-linkup
    down /usr/local/sbin/ovpn-linkdown
    local xxx.xxx.11.5
    lport 1195
    management /var/etc/openvpn/client1.sock unix
    remote xxx.xxx.11.2 1195
    ifconfig 192.168.80.2 192.168.80.1
    route 170.198.10.0 255.255.255.128
    secret /var/etc/openvpn/client1.secret

    The only rule on the OpenVPN tab is to allow all traffic.

    I am able to communicate to the DMZ from the LAN on the server side without issue.  I cannot access from the client LAN side.

    Thanks again for all the help.

    0
  • M

    So, you're using public IP's on your LAN… Why?  It may or may not be the main issue, but that should be changed.  Check your firewall logs for blocks.

    After the correction with the quotation mark placement by phil.davis and both DMZ and OpenVPN have any/any rules on the firewall?  It should be working.... but your tunnel network and DMZ are private... while the LAN on both sides are using publicly addressable IP's.... that HAS to be causing confusion somewhere.

    0
  • K

    Yeah…I walked into this mess with the public IPs being used, still not sure why they did that.

    I need to make a project to correct that first before I proceed.  After that I will revisit.  Thanks again for your help.

    0
  • K

    I made some changes and have a WIP to change the public addresses to 10.x.x.x on my lan.

    When I try to traceroute to the DMZ 192.168.64.1 from the remote side it hits the firewall and routes it out the WAN interface instead of passing it across the VPN tunnel.

    0
  • M

    Post new server1.conf and client1.conf and routing tables.

    Also, what is the client-side using for an IP range?

    0
  • K

    server2.conf:

    dev ovpns2
    dev-type tun
    dev-node /dev/tun2
    writepid /var/run/openvpn_server2.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
    up /usr/local/sbin/ovpn-linkup
    down /usr/local/sbin/ovpn-linkdown
    local xxx.xxx.11.2
    ifconfig 10.25.2.1 10.25.2.2
    lport 1195
    management /var/etc/openvpn/server2.sock unix
    push "route 170.198.10.0 255.255.255.128"
    route 10.25.1.0 255.255.255.0
    secret /var/etc/openvpn/server2.secret

    Client1.conf:

    dev ovpnc1
    dev-type tun
    dev-node /dev/tun1
    writepid /var/run/openvpn_client1.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
    up /usr/local/sbin/ovpn-linkup
    down /usr/local/sbin/ovpn-linkdown
    local xxx.xxx.11.5
    lport 0
    management /var/etc/openvpn/client1.sock unix
    remote xxx.xxx.11.2 1195
    ifconfig 10.25.2.2 10.25.2.1
    route 170.198.10.0 255.255.255.128
    secret /var/etc/openvpn/client1.secret

    How do I export the routing tables?

    My client side LAN is now: 10.25.1.0/24.

    Thank you again for the help!

    0
  • M

    You can either go to the shell and to a "netstat -r" or from the GUI it's Diagnostics -> Routes.

    0
  • K

    Well….I got it.

    I started poking around the routing tables after the last msg.  I needed to put a static route to the DMZ using the openvpn IP as the gateway.  Once I did that and added the vendor static routes that exist on the primary firewall to the remote firewall it all worked.

    Thanks marvosa for pushing me in the right direction.

    0
 

Products

Applications

Support

Services

News

Resources

Company

Our Mission

As host of the pfSense open source firewall project, Netgate believes in enhancing network connectivity that maintains both security and privacy. We also believe everyone should be able to afford it.

Subscribe to our Newsletter

Product information, software announcements, and special offers. See our newsletter archive for past announcements.

© Copyright 2002 - 2018 Rubicon Communications, LLC | Privacy Policy