Thread Info
  • State Verified Answer
  • +1 person also asked this people also asked this
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 5 subscribers
  • Views 12398 views
  • Users 0 members are here
Options
Suggested

ELI5: How do I do a "Business Rule" in v18 (firewall rule + NAT rule)

Antonio Cienfuegos S

Hi guys,

Been messing with the new version and Im not sure how to publish services to internet (Outgoing NATs are working fine)

What's the way to do it? What takes effect first?

 

Scenario (demo):

WAN (Port2):
192.168.12.90

LAN (Port1)
172.16.16.0/24 (.16 gateway / XG)

Host:
172.16.16.17

Im publishing any port (lets take for the sake of this example the safest port: 3389). How should I create the rules for this scenario?

Thanks in advance!!! Antonio.




[locked by: Stuart Hatto at 11:24 AM (GMT -7) on 15 Oct 2019]
[unlocked by: Stuart Hatto at 9:10 AM (GMT -7) on 16 Oct 2019]
Parents
  • +1

    Hi,

    When you create firewall rule for NAT rule in which destination is translated, you would need to match Dst zone as the ultimate zone in which the traffic would terminate (that is mostly the local zone – DMZ or LAN). However, you would (want to) match against the original destination IP (WAN IP on XG), here’s why:

    1. Usually one public IP would translate to different internal server IPs based on services. Admins can have one firewall access rule matching public IP; And NAT can take care of translating to different servers.
    2. Also, when admins add new servers in network, they need not to again modify firewall rule. With how this is implemented now – we can just edit NAT rule and we are good to go. This is true decoupled NAT/ Enterprise NAT power.
    3. Existing behavior makes it easier to configure in 1-to-Many DNAT scenario in which 1 public IP is translated against multiple local IPs. Match on the public IP adds flexibility.
    4. Industry implements DNAT in similar way. With v18, XG Firewall’s enterprise NAT capability is now at par with other competitive players.

     As we are moving to the new design, some confusion is bound to happen for existing users. We will soon support our veterans with detailed FAQs on community. Improvements in on-screen assistive text and online help is already in progress, along with the how-to-videos.

    Thank you very much for evaluating v18 early access. Appreciate your support.

Reply
  • +1

    Hi,

    When you create firewall rule for NAT rule in which destination is translated, you would need to match Dst zone as the ultimate zone in which the traffic would terminate (that is mostly the local zone – DMZ or LAN). However, you would (want to) match against the original destination IP (WAN IP on XG), here’s why:

    1. Usually one public IP would translate to different internal server IPs based on services. Admins can have one firewall access rule matching public IP; And NAT can take care of translating to different servers.
    2. Also, when admins add new servers in network, they need not to again modify firewall rule. With how this is implemented now – we can just edit NAT rule and we are good to go. This is true decoupled NAT/ Enterprise NAT power.
    3. Existing behavior makes it easier to configure in 1-to-Many DNAT scenario in which 1 public IP is translated against multiple local IPs. Match on the public IP adds flexibility.
    4. Industry implements DNAT in similar way. With v18, XG Firewall’s enterprise NAT capability is now at par with other competitive players.

     As we are moving to the new design, some confusion is bound to happen for existing users. We will soon support our veterans with detailed FAQs on community. Improvements in on-screen assistive text and online help is already in progress, along with the how-to-videos.

    Thank you very much for evaluating v18 early access. Appreciate your support.

Children
  • 0 in reply to PMParth

    PMParth said:

    4. Industry implements DNAT in similar way. With v18, XG Firewall’s enterprise NAT capability is now at par with other competitive players.

     As we are moving to the new design, some confusion is bound to happen for existing users. We will soon support our veterans with detailed FAQs on community. Improvements in on-screen assistive text and online help is already in progress, along with the how-to-videos.

    Thank you very much for evaluating v18 early access. Appreciate your support.

    Are you sure about that? This will bring a lot of confusion, dissatisfaction and a lot of Sophos customers call.

    Match on the public IP adds flexibility? More confusion, also, in this way NAT tab is becoming more important than Firewall tab. If you are troubleshooting or audit what is opening from external, you know that from internet, https or whatever is opened toward the XG WAN ip address.

    I cannot believe this! You are reiventing the wheel. NAT was much easier with v17. If you want to really copy, copy from other industry or even better for what you have in house (Astaro).

     

     

  • 0 in reply to PMParth

    Hello PMParth,

    OK, I get it now. The developers' lack of ability to implement properly standard security functions, which are used in the "original form" for quite a long time and EVERY firstly understand at first glance what the principle is, they now pretend to be a completely logical and innovative approach?
    Hmm, very good acting performance. So I am really curious how this new approach will appreciate the market and especially the administrators. I heard something very similar in 2015 when you released v15. I also heard from Sophos that it was a completely innovative approach, and for more than three years you patched and repaired the disaster and is it back?

    You NEVER learn!

    Regards

    alda

Unfiltered HTML