Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Unable to access the whole remote network only the firewall

    Scheduled Pinned Locked Moved OpenVPN
    7 Posts 3 Posters 1.9k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • L Offline
      lcorsini
      last edited by

      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?

      1 Reply Last reply Reply Quote 0
      • E Offline
        extide
        last edited by

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

        1 Reply Last reply Reply Quote 0
        • L Offline
          lcorsini
          last edited by

          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?

          1 Reply Last reply Reply Quote 0
          • E Offline
            extide
            last edited by

            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.

            1 Reply Last reply Reply Quote 0
            • L Offline
              lcorsini
              last edited by

              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

              1 Reply Last reply Reply Quote 0
              • M Offline
                marvosa
                last edited by

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

                1 Reply Last reply Reply Quote 0
                • L Offline
                  lcorsini
                  last edited by

                  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!

                  1 Reply Last reply Reply Quote 0
                  • First post
                    Last post
                  Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.