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

Update to 7.300 NAT issue

mhaug
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.
  • 0
    Interesting... according to the bugfix list, there was a NAT issue when ANY was used as a service that was corrected in 7.300 (I was one of the ones that reported it, it started showing up in 7.200)... sounds almost like the fix was to prevent folks from selecting ANY... interesting!

    CTO, Convergent Information Security Solutions, LLC

    https://www.convergesecurity.com

    Advice given as posted on this forum does not construe a support relationship or other relationship with Convergent Information Security Solutions, LLC or its subsidiaries.  Use the advice given at your own risk.

  • 0
    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
  • 0 in reply to DOXA
    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.
  • 0 in reply to Jack Daniel
    Isn't the DNAT for any service required if you need a DMZ? If the host is specified to be in a DMZ then it should accept ANY in its service.
  • 0 in reply to Flancer
    Only the specific ports and protocols required for public access to the servers in the DMZ should be allowed through.  Passing all traffic to the DMZ simply bypasses the firewall, exposing every open service to attack.

    The consumer router market has caused a lot of confusion by misappropriating the term DMZ.
  • 0 in reply to Jack Daniel
    Yes had this issue 2 updated only 6 of our 25 boxes but it take out all the DNAT rules and were having to manually put them in again on every box. Tested newer boxes that were loaded with 7.2 before config and they are fine wierd
  • 0 in reply to com2u
    @Jack Daniel:

    So using ANY for the service field in the DNAT/SNAT results in allowing traffic to bypass my firewall??? Although i set up packet filter rules to close not needed ports? 

    An nmap scan of an ip (server) in the DMZ (SNAT/DNAT rule used) says all is fine. Could i trust the results?

    Regards,

    Joerg
  • 0 in reply to Pretender
    I just removed the ANY service by clicking the garbage can in the service selector and that solved the problem for me.
  • 0 in reply to ErikFranzen
    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...
  • 0 in reply to Pretender
    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.
Cookie Information Banner