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

Cannot Access LAN using OVPN

Scheduled Pinned Locked Moved OpenVPN
10 Posts 4 Posters 1.7k 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.
  • S
    ShakMan
    last edited by Feb 18, 2015, 4:49 AM Feb 17, 2015, 6:01 AM

    First time post and thank you for helping. Here is my environment

    2.2-RELEASE (amd64) with 3 nic cards.

    WAN: Broadband ISP
    LAN: 192.168.1.X/24 (dhcp enabled via pfsense)
    OPT: 192.168.2.X/24 (connected to external access point and dhcp enabled via pfsense).

    OVPN Server: 10.0.1.0/24

    GOAL: Access workstation (RDP) and web sites on LAN (192.168.1.X) segment. I am connecting from Mac book Air using Viscosity (OS X Yosemite).

    Problem: Once connected (via Verizon mifi)  I cannot access any LAN resource. I can access pfsense web configuration server virtual interface on 10.0.1.1 but nothing else. I cannot ping any win7 workstations or web services on LAN.

    I am uploading my LAN diagram and server1.conf plus screenshots of setup.

    red-rule.jpg
    lan-rule.jpg
    ovpn-rule.jpg
    ovpn-status.jpg
    red-rule.jpg_thumb
    lan-rule.jpg_thumb
    ovpn-rule.jpg_thumb
    ovpn-status.jpg_thumb
    server1.conf.txt

    1 Reply Last reply Reply Quote 0
    • S
      ShakMan
      last edited by Feb 17, 2015, 6:13 AM

      Additional Screenshots

      general-information.jpg
      client-setting.jpg
      tunnel-setting.jpg
      general-information.jpg_thumb
      client-setting.jpg_thumb
      tunnel-setting.jpg_thumb

      1 Reply Last reply Reply Quote 0
      • D
        Derelict LAYER 8 Netgate
        last edited by Feb 17, 2015, 6:37 AM

        I don't think it'll matter but in your OpenVPN settings, conventionally you would specify 192.168.1.0/24 not 192.168.1.1/24 as the local network.

        Check that your settings on the Windows hosts allow connections in from "foreign" (not LAN) networks.  Also make sure that pfSense is set as the target hosts' default gateway.

        If you can ping 192.168.1.1 from the OpenVPN client that means all your routes and firewalls are right.

        Chattanooga, Tennessee, USA
        A comprehensive network diagram is worth 10,000 words and 15 conference calls.
        DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
        Do Not Chat For Help! NO_WAN_EGRESS(TM)

        1 Reply Last reply Reply Quote 0
        • P
          phil.davis
          last edited by Feb 17, 2015, 7:24 AM

          Coming from "MiFi" you should be OK after checking what Derelict suggests. But if you come from some friends home that already has 192.168.1.0/24 it will not work.
          I suggest you change the LAN/OPT networks at some "convenient" time to use more obscure subnets of IPv4 private address space.

          As the Greek philosopher Isosceles used to say, "There are 3 sides to every triangle."
          If I helped you, then help someone else - buy someone a gift from the INF catalog http://secure.inf.org/gifts/usd/

          1 Reply Last reply Reply Quote 0
          • H
            homeblt
            last edited by Feb 17, 2015, 3:28 PM Feb 17, 2015, 3:14 PM

            I have the exact same problem. I've searched for: "Check that your settings on the Windows hosts allow connections in from "foreign" (not LAN) networks." But not finding anything useful.
            I have several Windows7 machines plus Ubuntu running on my LAN …in a Windows workgroup. (except for linux machines) I don't have the subnet conflict issue as I am operating an obscure LAN subnet

            Any pointers?

            1 Reply Last reply Reply Quote 0
            • S
              ShakMan
              last edited by Feb 17, 2015, 4:22 PM

              @Derelict:

              I don't think it'll matter but in your OpenVPN settings, conventionally you would specify 192.168.1.0/24 not 192.168.1.1/24 as the local network.

              Check that your settings on the Windows hosts allow connections in from "foreign" (not LAN) networks.  Also make sure that pfSense is set as the target hosts' default gateway.

              If you can ping 192.168.1.1 from the OpenVPN client that means all your routes and firewalls are right.

              I will change to 192.168.1.0/24 tonight and test. All my hosts default gateway is pfsense. I did notice when I am connected, 198.168.1.1 brings up Verizon's mifi configuration page. As you can see that is my LAN segment. Could that be the problem?

              1 Reply Last reply Reply Quote 0
              • P
                phil.davis
                last edited by Feb 17, 2015, 5:23 PM

                I did notice when I am connected, 198.168.1.1 brings up Verizon's mifi configuration page. As you can see that is my LAN segment. Could that be the problem?

                Yes, I did not think that a service like Verizon MiFi would provide 192.168.1.0/24 subnet - I assumed they would use something a little more obscure for their client subnet.
                Change your LAN to some other private IPv4 subnet that is a bit more random.

                As the Greek philosopher Isosceles used to say, "There are 3 sides to every triangle."
                If I helped you, then help someone else - buy someone a gift from the INF catalog http://secure.inf.org/gifts/usd/

                1 Reply Last reply Reply Quote 0
                • D
                  Derelict LAYER 8 Netgate
                  last edited by Feb 17, 2015, 7:36 PM

                  Also, look at the DHCP the MiFi is giving you.  It's possible that before it's connected it's just redirecting everything to the config page.  If you're getting an IP on 192.168.1.0/24 and your default gateway is 192.168.1.1 then you'll know for sure that's the problem.

                  Chattanooga, Tennessee, USA
                  A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                  DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                  Do Not Chat For Help! NO_WAN_EGRESS(TM)

                  1 Reply Last reply Reply Quote 0
                  • S
                    ShakMan
                    last edited by Feb 18, 2015, 5:13 AM Feb 18, 2015, 5:08 AM

                    ok. Definitely made some progress tonight. It turns out my mifi admin page is 192.168.1.1(see image attached) which could cause issues routing (see image attached). Once the issue was identified, I had 2 options. (1) change my LAN IP segment or (2) quick change would be to change mifi LAN IP. I tried to put a new segment on the mifi admin page (192.168.10.X). But this was too easy :-) As it turn out there is NO way you could change this IP on Verizon mifi. I spent 2 hrs with their tier-2 support to change this but it seems like its hard coded in their firmware. Close but no cigar.

                    2nd try: Before I started making sweeping changes on my network, I realized my OPT segment is on 192.168.2.x. If I were to change this on my tunnel setting (see image attached) and test RDP and see if this would work. Initiated my OVPN connection on my mac and started to initiate RDP to 192.168.2.X. Viola….it worked.

                    Lessons learned:

                    1. Stay away from 192.168.1.X segment
                    2. Always check your own IP and gateway where you are initiating the connection from. In my case 192.168.1.1 is already used by mifi.

                    So phil.davis, there will be a "convenient" time for me to change my LAN segment. Many thanks for your help guys. Just a quick question on changing LAN ips on pfsense (I am a newbie)

                    1. If I change this on the interface page and change DHCP, will the existing firewall rules reflect this change automatically? Meaning everyplace I have 192.168.1.X be changed to 192.168.10.X

                    tunnel-setting-2.jpg
                    mifi.jpg
                    tunnel-setting-2.jpg_thumb
                    mifi.jpg_thumb

                    1 Reply Last reply Reply Quote 0
                    • P
                      phil.davis
                      last edited by Feb 18, 2015, 6:55 AM

                      Yes, it should be easy to change LAN subnet:
                      a) Change pfSense LAN IP
                      b) Change pfSense LAN DHCP range
                      c) Change OpenVPN server Local Network/s list - that cannot have things like LANnet specified, so it has a redundant 192.168.1.0/24 in it  :(
                      d) Check your aliases in case you have any that included specific addresses in 192.168.1.0/24 and fix as needed
                      e) Check your firewall rules for any specific uses of addresses in 192.168.1.0/24 (hopefully your rules all use aliases and/or the pre-defined LANnet and LANaddress - which will apply automagically)
                      f) Diagnostics->Edit File, /cf/conf/config.xml, search for "192.168.1" and see what other stuff is left behind
                      g) Change anything on LAN that has a static IP set (file server, print server, WiFi AP management interface…)
                      h) Get all LAN clients to renew DHCP

                      As the Greek philosopher Isosceles used to say, "There are 3 sides to every triangle."
                      If I helped you, then help someone else - buy someone a gift from the INF catalog http://secure.inf.org/gifts/usd/

                      1 Reply Last reply Reply Quote 0
                      10 out of 10
                      • First post
                        10/10
                        Last post
                      Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.
                        This community forum collects and processes your personal information.
                        consent.not_received