Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 5 replies
  • Subscribers 28 subscribers
  • Views 2220 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

Allow custom traffic to the XG Firewall (running on the XG Firewall)

Danny Meier

Hi,

Due to the lack of any support for multicasting (IGMP Proxy), I'm forced to do it by myself.

I have changed from a UTM 9 based firewall and are used to use any other kind of firewalls, but XG has really re-invented the wheel. With other words I'm a bloody beginner with a XG based firewall. Even simple rules / policies are like rocket science until the point the admin gets the idea behind the "new" way.

I'm running a custom service on the XG firewall (UDPXY) and that one is bound to TCP port 10000 (http traffic). The log output of the UDPXY mention, that creating the socket has been done successfully. But every try to access this services will fail because it's going to be blocked by the firewall.

Then I tried to create a new rule "Protect -> Firewall -> New User / Network Rule". I tried different combinations, but the simplest one with "any any" and only specifying the port (tcp 10000) does not work either.

Then I saw there is a configuration section called "System -> Administration -> Device Access -> Local Service ACL Exception Rule". But in here I can only add services which are predefined and covers the basic services offered by XG itself.

Any idea how to work around? If the product managers follows tightly the idea of future administrators are kids (I guess this is the direction they develop the XG product, not for professionals), then only applying custom iptable rules will help. But I really hope I have not to do this!

Thank you guys!

Cheers Danny



This thread was automatically locked due to age.
Parents
  • 0

    Basically Network Policies are from LAN to WAN.

    Business Application Rules are from WAN to LAN.

    This is the simple rule behind it. 

     

    As far as i can tell, 172.16.8.254 should be the XG Interface. So you need to build up a DNAT rule (Business Application). XG consider this traffic as "Appliance Access", because somebody tries to reach directly the XG Interface. And XG cannot do anything with this packets. 

    Your Firewall rule makes no sense, it allows this traffic to flow... Where? There is no destination at all. 

     

    Maybe you can work with PIM-SM, but i do not think, this will work..https://community.sophos.com/kb/en-us/123584

     

    Or you could deploy XG as a Bridge in this network. 

    https://community.sophos.com/kb/en-us/122973

    https://community.sophos.com/kb/en-us/123098

  • 0 in reply to LuCar Toni

    I guess there is a miss-understanding. At the moment most ISP in Switzerland (for DSL technology) do not offer CPEs with bridging capabilities (and in my rare case not even to any kind of configuration except defining a DMZ host. Not at least defining a different IP range for example). Therefor a double NAT scenario is the only solution to use a second router / firewall. The second router is assigned to the DMZ to get all the traffic originating from the real WAN. This setup is proofed and works with any kind of SOHO routers (including igmppropxy / udpxy). Also my old SG 115 Rev1 which I used before was able to handle this setup, so there is no issue.

    WAN: 192.168.0.0/24 -> .254 ISP Router, .253 XG Firewall (unfortunately a private class IP because of double NAT)

    LAN: 172.16.8.0/24

    So the traffic should flow from one of the LAN clients (e.g. 172.16.8.150) to the LAN Port of the XG (172.16.8.254). But this is blocked as you can see in the posted screenshot. There is no kind of NAT involved, the traffic never leaves the LAN.

    The idea of PIM-SM is not manageable. I have no idea of the RP Router and the ISP is not willing to tell any details even they support 3rd party modems / routers. Except of an multicast IP and a port is everything unknown. Reading all the posts in this forum, no one was able so far to use PIM-SM or any other XG/SG out of the box capabilities to solve this. For SG are some tutorials how to solve it by running your own igmpproxy or udpxy on the devices itself. I know I lose my warranty but better as throwing the Sophos devices into the trash. 

  • 0 in reply to Danny Meier

    Hi Danny,

    you misunderstood part of the answer. The suggestion was to put the XG in bridge mode.

    Ian

  • 0 in reply to rfcat_vk

    Maybe I really wrong, but if I put my XG into bridge mode then I cannot:

    • Port Forwarding
    • Defining my own private IP range and subnet (e.g. 172.16.x.x)
    • Configure DHCP in any kind
    • SSL VPN (remote access)
    • ...

    Bridge mode means transparent regarding all kind of routing, doesn't it?

    Because some ISPs (mine included) does not allow ANY change on the router. All I get from the ISP router is a dynamic private ip in the Range 192.168.0.x (1-253). Absolutely nothing configurable except setting one host as DMZ. In my case the XG is in the DMZ.

Reply
  • 0 in reply to rfcat_vk

    Maybe I really wrong, but if I put my XG into bridge mode then I cannot:

    • Port Forwarding
    • Defining my own private IP range and subnet (e.g. 172.16.x.x)
    • Configure DHCP in any kind
    • SSL VPN (remote access)
    • ...

    Bridge mode means transparent regarding all kind of routing, doesn't it?

    Because some ISPs (mine included) does not allow ANY change on the router. All I get from the ISP router is a dynamic private ip in the Range 192.168.0.x (1-253). Absolutely nothing configurable except setting one host as DMZ. In my case the XG is in the DMZ.

Children
  • 0 in reply to Danny Meier

    Yes and No.

    You will have a Layer 2 Bridge. But also you have the possibility to Act as a Layer 3 Bridge. So you can drop everything except some rules.

    XG will drop everything without any Policy. So you could design the Bridge as you wish, but you would have to deal with the DHCP Server of the router.

    Remote access would be possible. Instead of speaking to the XG WAN interface, you would talk to the XG Admin IP, which is based on XG bridge interface.

     

    But yes, this will have some dis advanced.

     

    I assume, you cannot resolve this Multicast scenario right now. XG misses the Proxy to handle this traffic. You could try to build a DNAT rule from LAN to WAN, but i am not sure, if this will work. A network rule will not work, like in UTM, firewall rules does not work. You would have to use NAT in this case.