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

Accessing VM on LAN interface when connected via WAN interface

Scheduled Pinned Locked Moved NAT
4 Posts 2 Posters 1.3k 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.
  • H
    husterk
    last edited by Sep 16, 2013, 5:28 PM

    I have a pfSense 2.0.3 box installed behind my Cisco ASA firewall / router via the pfSense WAN connection. I also have several VMs and other equipment on various VLANs and subnets on the LAN side of the pfSense box. When connected to the LAN side of the pfSense box everything works great. However, when I VPN into the Cisco ASA I would like to be able to acces the various equipment on the LAN side of the connection just as I would when connected directly to the LAN. Unfortunately, the best I have come up with so far is to NAT using Proxy ARP virtual IPs which leaves me with the scenario shown below…

    VM on LAN: 192.168.1.12

    pfSense WAN: 192.168.46.2
      pfSense LAN: 192.168.1.1
      WAN Subnet: 192.168.46.0 /24
      LAN Subnet: 192.168.1.0 /24
      Virtual IP for VM on WAN: 192.168.46.12

    IP Handed out by Cisco ASA: 192.168.47.0 /24

    Connecting to the VM via RDP works if I RDP to 192.168.46.12 however I cannot RDP to 192.168.1.12 unless I am directly connected to the LAN. I would like to always be able to RDP to 192.168.1.12 regardless if I am directly connected to the LAN or connected to the WAN via the Cisco ASA firewall. Hopefully this makes sense. Any help would be greatly appreciated!

    1 Reply Last reply Reply Quote 0
    • P
      phil.davis
      last edited by Sep 17, 2013, 7:01 AM Sep 17, 2013, 6:54 AM

      You should be able to do this just with some internal routes and pass rules.

      1. On Cisco add a route to 192.168.1.0/24 through pfSense WAN 192.168.46.2 (and that route will need to be pushed to the VPN clients that connnect to the Cisco, however you do that)
      2. On pfSense WAN add firewall rule to pass all source 192.168.46.0/24 destination 192.168.1.0/24 (or be more restrictive if you need to be)

      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
        husterk
        last edited by Sep 17, 2013, 4:23 PM

        Thanks for the tips… any chance I could make this work without needing to modify the Cisco ASA settings? I may not have access to this device.

        1 Reply Last reply Reply Quote 0
        • P
          phil.davis
          last edited by Sep 17, 2013, 6:03 PM

          @husterk:

          Thanks for the tips… any chance I could make this work without needing to modify the Cisco ASA settings? I may not have access to this device.

          I can't think how to do that - the Cisco needs to know somehow that the pfSense WAN IP is a gateway to 192.168.1.0/24
          Your NAT solution is the standard way, essentially faking the pfSense LAN side address using a WAN side address that the Cisco is already happy to talk with.
          By the way, if you do change the Cisco to add a route to 192.168.1.1 then you will have trouble when you VPN in to the Cisco from your favourite cafe/friend's house that is using 192.168.1.0/24 locally. If possible, I would change the LAN subnet to something less common - out of the 10.0.0.0/8 space or 172.16.0.0/12 space or down the end of 192.168.0.0/16.

          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
          4 out of 4
          • First post
            4/4
            Last post
          Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.
            This community forum collects and processes your personal information.
            consent.not_received