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

Update to 7.300 NAT issue

I just had a "gotcha" that may get others:

After applying 7.300 update, all of my NATS were disabled. Enabling them caused an error. This was due to my use of the service type "ANY".

A quick work around is to make a group called "Everything" or "ALL"....etc
and add the existing "ANY" service to it.

Change your NATS to use this new group and all will be fine.

Hope this helps someone.

Matt


This thread was automatically locked due to age.
Parents
  • Its-not-a-bug-its-a-feature

    ID08254 7.104 Using service 'Any' as traffic service breaks DNAT and SNAT rules
    --------------------------------------------------------------------------------
    Description:  Adding DNAT/SNAT rules with service 'Any' will not work.
                  When updating to 7.300 these rules will get disabled
                  automatically.
    Workaround:   Please use one of the predefined service definitions or add
                  a new one matching your target service.
    Fix:          Fixed in 7.300
  • Bruce is right, this was disabled to prevent the problems he (and many others) experienced when use of the ANY service group caused conflicts in the NAT rules.  I would recommend defining the NAT rules as tightly as possible to prevent conflicts.
  • It would be interesting if BOTH - DNAT/SNAT rules - will be disabled. Or if the issue only applies to DNAT. That would be no problem for me...
  • No, if the packet filter rules block the traffic, it is blocked- but with the handly little "auto packet filter rule" checkbox, there is the potential for a mistake in a NAT rule using the "any" service is high.

    The most common issue that I have seen with "any" is that it frequently creates conflicts and overlapping rules resulting in "unexpected" behavior.
  • I would never use this "handy" little feature. I don't trust automatisms.

    But would you be so kind to answer my question, what will happen to my SNAT rules if i use ANY in the service field?

    Regards,

    Joerg
  • I posted this exact scenario in another thread and not to intentionally duplicte a thread, but I have dnat rules set up on each of my external IP's to be used as the "last rule" for each to take any source IP, and any source service to my external IP and forward it to a non-existant IP, and any destination service as a method of making all of my unused ports/IP's "stealthy" or in other words send the traffic to a blackhole. 

    Essentially, I defined all of the services I wanted to put through first and then followed that with the blackhole rule. I did this as otherwise, when someone does a port scan on your network, they will get a response back saying port closed thus identifying your network is there. This then results in additional scanning by these rogue bots causing increased unwanted traffic. 

    I am going to try to create a service group containing any and see how that goes. 

    I suspect that someone could easily select any to a valid internal IP thus opening it up completely so this is a method for astaro to prevent someone from themselves... we all make mistakes I guess but if you are programming a firewall you should know what you are doing and not make this mistake!?!?
  • I would never use this "handy" little feature. I don't trust automatisms.

    But would you be so kind to answer my question, what will happen to my SNAT rules if i use ANY in the service field?

    Regards,

    Joerg


    It simply means that all services are allowed to pass outbound from the internal IP to the external translated IP unless explicitly blocked by a packet filter rule.

    Using Any in the source of a SNAT rule this is basically inverting the standard logic of "everything is blocked outbound unless explicitly allowed out by a packet filter rule. The same would hold true for DNAT rules - using Any would allow all service ports in unless explicity blocked by a packet filter rule, which of course is even a more dangerous scenario.
  • It simply means that all services are allowed to pass outbound from the internal IP to the external translated IP unless explicitly blocked by a packet filter rule.


    Thx for your explanation. But i only wanted to know if all SNAT Rules with ANY would be disabled. Nothing more.
  • But would you be so kind to answer my question, what will happen to my SNAT rules if i use ANY in the service field?


    I hate to give a vague answer, but it really depends on the remainder of your configuration.  In my personal experience, the simpler the ruleset, the less likely you are to have issues with an "any" rule.
  • Thx for your explanation. But i only wanted to know if all SNAT Rules with ANY would be disabled. Nothing more.


    Sorry, I misinterpreted your question.
  • This is a big freaking mistake if you ask me.  Morons that don't know what they're doing running a firewall are being prevented from screwing things up by these stupid "helpful" changes Astaro makes and those of us who have ANY rules in our configs for a damn good reason get completely screwed after the upgrade to 7.3.  Astaro is a decent product but they consistently drop the ball on communicating things like this.

    I just spent an hour fixing NAT rules that should not have been broken.  If I want to create NAT rules based on ANY service, then I should be able to do it.

    Based on Astaro's update track record I should kick myself in the freaking ass for even upgrading to 7.3 until at least 45 days had passed.
  • This is a big freaking mistake if you ask me.  Morons that don't know what they're doing running a firewall are being prevented from screwing things up by these stupid "helpful" changes Astaro makes and those of us who have ANY rules in our configs for a damn good reason get completely screwed after the upgrade to 7.3.  Astaro is a decent product but they consistently drop the ball on communicating things like this.


    I agree with this 100%!

    Regards,
    Manuel
Reply
  • This is a big freaking mistake if you ask me.  Morons that don't know what they're doing running a firewall are being prevented from screwing things up by these stupid "helpful" changes Astaro makes and those of us who have ANY rules in our configs for a damn good reason get completely screwed after the upgrade to 7.3.  Astaro is a decent product but they consistently drop the ball on communicating things like this.


    I agree with this 100%!

    Regards,
    Manuel
Children
No Data