Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 6 replies
  • Subscribers 4 subscribers
  • Views 10826 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Routing HTTP(S) traffic outside of Site to Site SSL VPN

Nick Page

Hi,

We've only had our SG430 a few months and for the most part have figured out how to do what we want it to do. The one thing I cannot figure out is this.

We have an externally hosted website that internal users need to access, this external site also needs to be able to read data from an internal SQL server. The thought is that we would set up a site to site SSL VPN on the firewall which would allow the external server access over the SQL Protocol to the SQL Server only (no other access to the internal network, no other protocols allowed to the SQL server). We set up the VPN connection and are waited for the external hosting company to configure their end. We then noticed that internal users were suddenly unable to access the webserver via HTTP. When we did a tracert the traffic stopped at the firewall. It wasn't until we disabled the VPN connection that access was restored to the website.

It seems like the SSL VPN routing is sending all traffic destined for the external webserver via the VPN connection (regardless if it's connected or waiting connection), how do I separate the traffic so only SQL goes over the VPN and the HTTP traffic goes via the external interface.

 

I thought about doing some sort of load balancing or multi path thing, but the VPN connections don't show as interfaces so I'm not sure how to fix this.

 

Thanks in advance for any help you might be able offer.

 

Regards,

 

Nick



This thread was automatically locked due to age.
  • 0

    This shouldn't happen if you only have internal ip-ranges in the VPN tunnel. Next your web-server should resolve to its public (external) IP-address.
    You can choose to go to the webserver by it's internal address but yes, then it can only go through the tunnel.

    Perhaps you can show some screenshots of the VPN configuration at your end.

    And is there a special reason for choosing site2site using SSL rather than IPSEC?

    Managing several Sophos firewalls both at work and at some home locations, dedicated to continuously improve IT-security and feeling well helping others with their IT-security challenges.

  • 0

    Hi Nick,

    Interesting issue you have there, it is weird that the HTTPS traffic destined for the webserver is being affected by the S2S VPN tunnel, is it possible that there is some kind of split brain DNS issue that the UTM may be suffering from?

    Additionally, you could set up a host definition on the UTM that has the public IP with the reverse DNS set to the public FQDN of the webserver, this should prevent the UTM perceiving the SQL server as an internal IP that should be destined for the SSL S2S tunnel. Failing that, a TCPDump should be done, so we can see exactly what is happening for the packets if the host definition fails.

    Emile

  • 0 in reply to apijnappels

    Hi,

     

    Thanks for your response, Below is a snip of the VPN config

     

     

    Thrall-ii (Internal SQL Server)

    Moodle Host (External Webserver)

    Static Peer IP is NOT part of our internal subnet it was just an easy IP to track if we needed to.

     

    I've tried using the auto generate firewall rules and also creating my own firewall rules. Below is a snip of the current rules.

     

    There was no specific reason to us SSL VPN over IPsec.

     

    Regards,

     

    Nick

  • 0 in reply to Emile Belcourt

    Hi,

     

    Thanks for your response, Please see screen shots of existing config this may help explain the situation better.

     

    I need to establish a secure connection between the external webserver and the internal SQL server for SQL traffic only. Any HTTP traffic destined for that webserver should continue to go out via the external interface of the UTM not via the VPN connection. The external servers FQDN is specified in our internal DNS to ensure that internal clients resolve the domain to it's external public IP and not the IP of the VPN connection.

    Hope that makes sense.

    Regards,

     

    Nick

  • +1 in reply to Nick Page

    Your problem I think is in the local and remote networks specified.

    In local networks you need to have only your SQL-server (which you have), in remote networks it needs the internal IP-address of the webserver (its local address not its external public address).

    Your firewall rules should also use the local addresses of both sides (you want the webserver to talk to the SQL-server over the VPN which they should do over their local IP-addresses).

    Also with the SSL-VPN you will always have additional addresses to deal with (SSL uses its own addresses it hands out to clients).

    Managing several Sophos firewalls both at work and at some home locations, dedicated to continuously improve IT-security and feeling well helping others with their IT-security challenges.

  • 0 in reply to apijnappels

    Hi,

     

    Ah ha! of course it's a tunnelled connection (face palm) that makes sense now, I've been using the external IP of the webserver. [:$]

    I'll get in touch with the hosting company and get the internal IP. I did looking at the routing table with the VPN enabled that it was creating 2 additional routes one for the external IP and one for the static virtual IP both of which had a gateway IP from the VPN IP Pool I assume this is what you're referring to when you say additional addresses. I'm guessing the virtual static IP would only be needed it the webservers internal IP is in a range used by my site. If that is the case should the firewall rules reference the webservers internal IP or the virtual static IP ? 

    Thanks for you help, it seems so obvious now.

    Regards,

     

    Nick

Unfiltered HTML