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

Prevent WAN access on additional IP address.

To map a public address to an internal address in the UTM-9, my understanding is that under "Interfaces" > "Additional Addresses" > I add a new address and assign it to the Outside interface.

Then create a NAT that for instance maps ANY service coming from ANY source going to this Additional address gets translated to the internal address that I choose.

My problem is that now I can manage the firewall using the additional address.
For instance, if the WAN address of the UTM is 65.65.65.60 and the additional address is 65.65.65.70, I can now managed the UTM using:

https://65.65.65.60:4444/ and https://65.65.65.70:4444/


How do I prevent https://65.65.65.70:4444/ form working.

I tried firewall rules such as, traffic from ANY using service 4444,80,443 going to 65.65.65.70, drop or reject. But it doesn't change anything.

Any help would be appreciated.


This thread was automatically locked due to age.
  • Hi spacemancw,

    have a look at "Management" --> "Webadmin Settings" --> "Allowed Networks".
    Here you have to specify the Interface for Webadmin-Connection.
    Or you have specified your personal Public-IP to remote administrate your UTM. Then you also have access on all Interfaces.


    Regards
    Thorsten
  • Hi ThorstenS, thanks for the reply. Unfortunately that is not where the issue lies.
    The Allowed networks tell us what Sources are allowed to manage the firewall. I have this locked down to our offices, it's not ANY.
    The issue is really the opposite of this, it's the "destination" that is allowed to be managed that I'm trying to control.
  • Why shouldn't it be allowed to open the webadmin from this IP when the Webadmin can be accessed over the primary ip as well? I can't see a reason [:)]
  • Solae, I want the primary IP to be the firewall IP, the additional IPs to be for a web server, a mail server, an application server, a CSG ... and so on.
    I do not want every additional IP to be a way to manage the firewall.
    If I do an audit of the IPs, I do not want everyone of them so say that ports 4444 and 443 are open.
  • Hi, spaceman, and welcome to the User BB!

    Check out #2 in Rulz.  You only need to blackhole 4444&443 coming to your secondary addresses.  Pay attention to #4 in Rulz for this.

    Cheers - Bob
  • Thanks BAlfson. I tried to do what I think you suggest. Tho not quite sure how to blackhole.
    I created a DNAT that says traffic from ANY using 4444 Going to "Outside [SecondaryIP](Address)", change destination to "some other internal IP", service [blank].

    Did another one like this for https.

    Put these 2 in positions 1 and 2.
    but https://secondaryIP:4444 still works.

    I also have a rule in position 1 that says sources ANY, service 4444, HTTPS, destination "Outside [SecondaryIP](Address)", Reject or drop.

    No joy.
  • Yes, your DNAT is the way to blackhole a packet to a non-existent IP.  If it's not working, please press [Go Advanced] below and attach a picture of your DNAT open in Edit mode.

    Your firewall rule is ineffective because WebAdmin and the User Portal have firewall rules that come before the manual rules (#2 in Rulz).

    Cheers - Bob
  • You can't see the full text of the "Going to" field, but is says "Outside [OMSAPP](Address)". OMSAPP is the name of the server behind the NAT.

    I change destination to an object called Blackhole, which is an IP address of 192.168.1.1, which does not exist.
  • Can you see in the Firewall log that the incoming packets are selected by your DNAT rule?  Is 192.168.1.0/24 the subnet of "Internal (Network)?"

    Cheers - Bob
  • I have two DNATs, one for 4444 and one for 443, both going to the Blackhole.
    I can see Firewall Log entries for the 443 DNAT, but I don't see any for the 4444 DNAT.
    Yes the blackhole address is on the internal network. I've also tried a blackhole IP address that wasn't part of any of the networks on the interfaces.