Results 1 to 4 of 4
  1. #1
    Master Untangler engine411's Avatar
    Join Date
    Dec 2008
    Posts
    280

    Default Verifone MX device needs local LAN through VPN

    Hi everyone.
    We have Untangle, latest version, at the network edge at our headquarters. Our point of sale software requires that the Verifone MX credit card device have a local LAN address on the same DHCP scope, 10.1.1.x as the inhouse point of sale server. So, the server is 10.1.1.5 and the point of sale station is 10.1.1.100 and the MX credit card device is 10.1.1.101. Inhouse, that's easy to do.

    Now, our company is opening an offsite stand at a farmers market, and I have a new point of sale Surface tablet and an MX device to use at the market. Internet access there will be provided by an AT&T hotspot that we own. I don't know if the dynamic WAN IP that the hotspot pulls from AT&T will be an issue or not (no static IP). I can set the point of sale station and the MX with a static IP or using DCHP, whichever will work best.

    I need the MX at the offsite market to have a 10.1.1. address and be able to see the server back at headquarters - through a VPN that is connected via the internet from the hotspot. The MX device won't work if it has a different scope at the remote end of the vpn, I.e. something like 192.168.10.1 that is different than the local LAN at headquarters.

    Question 1 - is this possible with Untangle?
    Question 2 - if yes, which VPN app would work best?
    Question 3 - If the two point of sale devices have static 10.1.1.x addresses, what configuration is needed on the VPN and/or hotspot so those devices can see the point of sale server back at headquarters in order to accomplish all this?

    TIA.
    Lonnie, in Bird-in-Hand, Pennsylvania, a Firefighter to the Core (i7)
    Owner - Kauffman Orchards

  2. #2
    Untangle Ninja sky-knight's Avatar
    Join Date
    Apr 2008
    Location
    Phoenix, AZ
    Posts
    26,239

    Default

    No, it's not possible with Untangle, and for that matter isn't not really possible for ANYTHING.

    So my question becomes, why does this device have such an asinine requirement? It's 2021, not 1990. IP is meant to be routed, and devices need to deal with this fact. Which generally means auto-discovery mechanisms need to be able to deal with that fact... via DNS record or manual IP input.
    Last edited by sky-knight; 11-04-2021 at 08:35 PM.
    Rob Sandling, BS:SWE, MCP
    NexgenAppliances.com
    Phone: 866-794-8879 x201
    Email: support@nexgenappliances.com

  3. #3
    Master Untangler engine411's Avatar
    Join Date
    Dec 2008
    Posts
    280

    Default

    Sky, thanks.
    To clarify, even if I have a 2nd Untangle at the market doing a site to site vpn, this isn't possible?

    The issue is not the device, it's the software we use. It has weird requirements, and it's not easy to swap out software, although we are headed in that direction but that's not a solution for the present need.
    Lonnie, in Bird-in-Hand, Pennsylvania, a Firefighter to the Core (i7)
    Owner - Kauffman Orchards

  4. #4
    Untangle Ninja sky-knight's Avatar
    Join Date
    Apr 2008
    Location
    Phoenix, AZ
    Posts
    26,239

    Default

    No, all VPNs in Untangle are routed, there are no bridge options. But even if there was, the device itself lacks the ability to have the software client installed on it to make it all work. Bridge based VPNs are their own problem, one that I actively avoid for many reasons which is why I'm glad Untangle is routing VPN ONLY.

    This sort of thing is solved in the CISCO world with something called proxy ARP. It in theory can be replicated with Untangle via a combination of port forward rules, and NAT policy.

    The idea is you make an IP address on the software hosting side of the network's Untangle that would have all communications forwarded to the real IP of the remote device. You'd then have a NAT policy that would force all traffic from that remove device to be translated to that local alias address before it makes its way back into the LAN. Finally you'll need a port forward rule to capture all egress traffic from the remote device and forward it to the software side Untangle for further processing.

    It's one of those things that has a ton of moving parts, and if any one of them isn't configured correctly things simply do not work, there's no logging to help you troubleshoot, only packet captures. And even if you do all this correctly, there's no guarantee the DRM in your software is going to be OK with it.

    The problem here is that software, so yes... you need to get rid of it. Those sorts of limitations should have all died in a fire with the 2000s at least.

    Anyway, if you can follow the above and want to attempt it, the goal is to have the "local" Untangle have an IP address on it that is for all intents and purposes, the remote device. The software shouldn't even know or care this is happening, nor the device. The two Untangle servers are doing all the translating to make it all happen.
    Rob Sandling, BS:SWE, MCP
    NexgenAppliances.com
    Phone: 866-794-8879 x201
    Email: support@nexgenappliances.com

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

SEO by vBSEO 3.6.0 PL2