Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 10 replies
  • Subscribers 2 subscribers
  • Views 16285 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

[SOLVED]Additional addresses (alias) configuration

GabrieleDelconti
Hello,

as Application Service Provider we have several UTM connected to internet uplinks via dedicated transfer (somewhat called "glue") /29 network, then a pool of public IP, on which our Virtual Hosts are mapped to, is routed behind the public IP of the UTM WAN interface (which belongs to the glue network).

The above configuration is pretty standard. Other vendors, for example Checkpoint, do not require any Alias or proxy arp configuration. Packet routed to the WAN interface are captured by the firewall engine and processed accordingly security and NAT rules.

It seems that Sophos UTM require Additional Address configuration for each and every IP to be captured and processed even if these IPs belong to a subnet that is already routed to the WAN IP.

How these additional address should be configured, specifically:

1) can the entire Virtual Hosts subnet, let's say /24 be configured as a single item or each IP need to be added one by one?


2) How the network mask has to be defined?
The official documentation says nothing abut this and I have found here discrepant information: /32, the mask of the WAN interface (which is not relevant in our case), the mask of the subnet of IP routed behind the WAN, ...



Thank you in advance for clarification.

_lele_


This thread was automatically locked due to age.
Parents
  • 0
    For HTTPS, you only need one public IP for Webserver Protection as differentiation is made based on the certificate.

    If you are hosting 100 domains that use HTTP, I would use the public IPs on the servers themselves and not use Webserver Protection.

    Do let us know what you decide.

    Cheers - Bob
Reply
  • 0
    For HTTPS, you only need one public IP for Webserver Protection as differentiation is made based on the certificate.

    If you are hosting 100 domains that use HTTP, I would use the public IPs on the servers themselves and not use Webserver Protection.

    Do let us know what you decide.

    Cheers - Bob
Children
  • 0 in reply to BAlfson
    For HTTPS, you only need one public IP for Webserver Protection as differentiation is made based on the certificate.

    If you are hosting 100 domains that use HTTP, I would use the public IPs on the servers themselves and not use Webserver Protection.

    Do let us know what you decide.

    Cheers - Bob


    Bob, our business is SaaS. We generally do need separate IP for each client for several reasons that are not relevant here (while we use domain-based instance whenever feasible). Webserver protection, http, https are not related to may question.

    My question was focused on different behaviour between Sophos UTM and and UTM from other vendors, notably Checkpoint which we extensively use since 2001 in our nine hosting locations worldwide.

    In short:

    [FONT="Courier New"]UTM WAN IP ---uplink---ISP ROUTER---internet

    ^^^^^^^^^^^^^^^^^^^^^ this is a small interconnection (glue) subnet, usually /29
    [/FONT]
    One or several subnets of public IPs are routed toward UTM WAN IP by the ISP as next hop. The above configuration is pretty standard and used worldwide by ISP serving SaaS providers like us.

    Checkpoint: UTM does not need to proxy arp each public IPs since these additional IPs are already entering the UTM, thanks to the next hop route configured by the ISP.

    Sophos: additional IP configuration is required, otherwise the UTM does not capture the incoming traffic directed to the public IPs belonging to the networks of additional IPs provided by ISP (or by us where we act as LIR).

    Anyway the problem is solved configuring each IP as additional /32 IP on WAN interface whit the minor problem described in the attached image above.

    _lele_