Squid Reverse Proxy Not Working

  • I have a unique situation, I was hoping to get some assistance with.

    We have use a web based portal, that can only be accessed from our internal network or via VPN.  We have a mobile application that has to access the web portal, but we are finding users keep forgetting to connect to the VPN, and thus have issues accessing it.

    To make it easier, I am trying to setup a reverse proxy that will setup connections from anywhere on a WAN port, and pass it thru to the LAN interface, that then will go thru our network to the web portal, then have the whole thing go back to the mobile device.

    I believe I am getting stumped at the reverse proxy, as I can connect to the firewall via the WAN port, and can get the squid error message, but it doesn't seem to hand off to the IP of the web app.

    Since it is not using SSL, I have http configured to connect on the proper port, and I have the Mappings configured to the peer, but nothing goes to the website.

    Any advice would be helpful.  In addition, if you need configuration information or anything, let me know.

  • I don't have a definite answer for you, mostly thinking out loud for now, hoping you might get some insight from my ramblings.

    No offence intended but from my understanding it looks like you're trying to include a breach in your network to make the current architecture easier to use.

    Maybe the web based portal would have been better implemented in the cloud so that any access to it would be treated the same way.

    One path that you might wish to explore is to set up a computer in your internal network in a way that it receives all requests from the app, pass them to the web portal and back. Then set a port on the WAN interface that directs all the packets it receives to the designated computer in your lan for the web portal requests.

    To keep things safe, each request shall include something like one string of info able to identify who sent the request, one string of info that somehow checksums both the user and time of request so it can't be just copied and sent later in an attempt to hack your network, finally the request.

    Then the designated PC can validate each request and only responds to the legitimate ones. Of course there's the risk of it being flooded with requests, etc. so the added safety layers might make this solution kinda complicated.

    A more interesting path would be to simply have the app check if the user is from the internal network before accessing the web portal… like setting up a server completely out of your business that returns "congratulations you are logged in to the VPN or in our LAN" if the request come from a specific IP address, otherwise it just returns "please make sure you are connected to VPN before going further".

    Basically it can be a simple byethost, hostinger, etc. webserver with a simple script that validates from which IP range the request is from, then the app remind the users to log in to the VPN if the IP is anything else than the IP address the router can have on the WAN.

    Or maybe simply have a server on 192.168.x.x in your LAN that replies the same thing to all requests, have the app checks first if it gets the right reply from this exact IP before connecting to the web portal. If the user is on any other LAN, the app just won't get the right answer so will ask the user to connect to the VPN first.

    So instead or risking to compromise your network, just find a way to detect the users who aren't using the VPN or are in the LAN and remind them to login there first before using the app.

    In order to make things simpler once this is set up, you can have an access point in the office which is already part of that network, where all mobile devices automatically connect to so they don't have to connect through the VPN as long as they're within range.

    I hope this helps, best regards

  • You are 100% right…except your aren't.

    We have a secured internal network, what I am proposing is taking a spare public IP on my backup internet connection, and having it only accept packets going to that port, and forwarded to the internal LAN to forward it to the IP in the cloud.

    The system is in the cloud, however they won't open external ports on their firewall, which is annoying. We generally like the idea of using the VPN to keep things secure, but our employees are....dumb, and instead of hitting the giant button that says "reconnect" if it loses cell reception, they just complain it doesnt work, and then we end up losing the ability to track our fleet.

    Sorry for the confusion, you are generally right, however we are taking every precaution to secure the situation

Log in to reply