Unable to access the whole remote network only the firewall



  • Hello, I've encountered a problem that I'm not able to fix
    I've created an openvpn server following this howto:
    http://www.packetwatch.net/documents/guides/2012050801.php

    10.0.8.0/24 is the virtual network
    192.168.129.0/24 is the remote network

    everything seems to be correct, the tunnel goes up nicely but I can connect only to 192.168.129.254, which is the pfsense address on the remote side, if fo example try to ping or connect to a linux machine at 192.168.129.253 it goes in timeout.

    I use viscosity as my openvpn client on OSX 10.8 with the connection esported from pfsense, here is the configuration

    #– Config Auto Generated By Viscosity --#

    #viscosity startonopen false
    #viscosity dhcp true
    #viscosity dnssupport false
    #viscosity name AssindustriaMS
    remote REMOTEADDRESS 1194 udp
    pull
    auth-user-pass
    tls-client
    tls-auth ta.key 1
    persist-key
    ca ca.crt
    dev tun
    persist-tun
    cert cert.crt
    comp-lzo adaptive
    key key.key
    dhcp-option DNS 192.168.129.254
    dhcp-option DOMAIN assindustriams.lan
    cipher BF-CBC
    tls-remote lucac81
    resolv-retry infinite

    the strange thing is the routing table on my mac here is a snippet of it:

    buffy:~ lucac81$ netstat -f inet -nr
    Routing tables

    Internet:
    Destination        Gateway            Flags        Refs      Use  Netif Expire
    default            192.168.199.1      UGSc          127        0    en1
    10.0.8.1/32        10.0.8.5          UGSc            0        0    tun0
    10.0.8.5          10.0.8.6          UH              4      47    tun0
    192.168.129        10.0.8.5          UGSc            1        5    tun0

    What should I look at to solve this problem?



  • The routes look correct, I am guessing you have firewall rules blocking the traffic from getting to the machine behind the firewall.



  • The pfsense wizard generates the rules needed to make the traffic pass I think, I'll check them better, in the OpenVPN rules section there is one roule that allows everything from the openvpn interface

    The routing table sounds strange to me only because my previous experience was with pfsense 1.2.3 and a shared key approach, in which the route appears like this (is tun1)

    default            192.168.199.1      UGSc          122        0    en1
    10.0.1.1          10.0.1.2          UH              2        1    tun1
    10.0.8.1/32        10.0.8.5          UGSc            0        0    tun0
    10.0.8.5          10.0.8.6          UH              3      17    tun0
    192.168.99        10.0.1.1          UGSc            0        0    tun1
    192.168.129        10.0.8.5          UGSc            1        0    tun0

    so a point to point to the pfsense end point and a static route to the remote network passing thru the endpoint

    maybe with user auth+tls is different but I don't completely understand it, if 10.0.8.1 is the pfsense virtual address, and 10.0.8.6 is my endpoint address, what is 10.0.8.5?



  • I'm not exactly sure why 10.0.8.5 get's used, but that is how my routing tables look on my openvpn configs, and they all work fine.

    One way to see if it is indeed a route problem or a firewall problem, is by doing a traceroute. You should see 10.0.8.1 as the first hop, and then it should try to get to 192.168.129.x.



  • traceroute gets starred out even if I trace to the firewall so I can't see anything…
    I don't really know where to look ??? ??? ???

    EDIT traceroute using ICMP ECHO indeed shows that it passes on to 10.0.8.1 when trying to reach a remote lan ip, but then it stops there, so maybe is a firewall rule, the problem is which one, on openvpn there is one rule that says pass everything to every interface, on the wan side there are nat rules, and on the lan side there is one rule that blocks only port 25 outgoing and disabling it doesn't affect the vpn



  • Post network map, server1.conf and firewall rules on the openvpn tab.



  • I've solved it, it was a stupid mistake…. on the machine I was trying to reach!!!!  >:(
    192.168.129.253 it's the linux machine that I was trying to reach, it has a second eth interface with address 10.0.0.1 and (wrong!!!!) netmask of 255.0.0.0
    So I was reaching the machine, but packets got forwarded to the wrong interface instead of going back, hence the timeout!!
    Putting the right netmask solved the problem, now everything works fine.
    Lesson learned!


Log in to reply