Not forwarding LAN to LAN routed HTTPS traffic

I'm running the current beta firmware and am having problems with the firewall not forwarding LAN to LAN https traffic.

Port 1 LAN 10.0.20.1/24

Remote network - 192.168.99.0/24

Router to remote network 10.0.20.254

I have created a static route and LAN to LAN firewall rule.  The firewall rules is a ANY to ANY with ANY service allow rule with malware scanning disabled, and all advanced features such as IPS, Traffic shaping, and web policy configured as None.  I also have NAT disabled.

From my computer 10.0.20.97/24 with gateway 10.0.20.1 I am able to successfully connect to the remote web server 192.168.99.8 via ping and view and http web page.  The packet capture shows both the incoming traffic on Port 1 and forwarded traffic out on Port 1.

When I attempt to connect via https in either IE, Chrome, or Firefox the page does not appear.  The packet capture shows the incoming TCP 443 on Port 1 and the next packet shows as Consumed.

Why is the firewall not forwarding the HTTPS traffic?

  • I'm seeing this too.  It's not limited to port 443 either.  I have noticed that 4444 is being blocked.  It appears IPS is detecting and blocking all HTTPS even if IPS is disabled from what I can determine on the logs.

    If you stop the IPS service (System Services > Services) it should all work again.  Not that this is a long term solution but does confirm that it is IPS related.

  • Just tested on Beta 5 and the firewall is still not forwarding HTTPS port 443 traffic.  All other traffic DNS, Kerberos, LDAP, HTTPS... is successfully being forwarded to the remote network.

    The most frustrating part of troubleshooting is not getting enough information from the built-in tools including the logging and packet capture feature to figure out the issue.  The firewall is allowing the traffic, but can't figure out why it is not being forwarded.

  • Do you have a rule that manages 443 higher up the priority list?

    Ian

    XG115W - v20.0.1 MR-1 - Home

    XG on VM 8 - v20 GA

    If a post solves your question please use the 'Verify Answer' button.

  • I have no rules above that would be blocking 443. 

    The only rule above is a LAN to WAN firewall rule allowing all traffic

  • RichardHamaura said:
    The most frustrating part of troubleshooting is not getting enough information from the built-in tools including the logging and packet capture feature to figure out the issue.

    Sorry to hijack your thread but this is ridiculous. Since the beginning of the beta we have been asking for improved logging. No, let me take that back, we have been asking for improved logging since v15 beta of this firewall. We keep on hearing about how the things added to the new v16 are the features most requested by the partners... Really???

    How many times do people have to ask for improved logging?

    Why is it OK for the logs to disappear if you reboot the firewall?

    How hard is it to grep conntrack entries and present them in a readable format to the admin?

    Why does sophos think that packet capture is a substitute to good logging?

    Why does sophos keep on ignoring ALL the beta testers? Why doesn't anyone EVER answer our concerns? 

    XG v16 will be GA shortly. Can anyone really see the difference between beta1 and beta5? Sure a lot of bug fixes but ALL the beta feedback/feature request categories might as well have been directed to /dev/null just like the logging in XG. Nothing to see move along[:#] but but but there is packet capture[8-|] What a disappointment...

  • I have found a resolution.  On my LAN to LAN Any Allow rule, I had to enable NAT Masquerading with an outbound address of my Port 1 LAN ip. 

    My https traffic is now working.  Not sure why I had to create a NAT rule for traffic traversing over a routed network to get the https traffic to work.

  • HI RichardHamaura, 

    The NAT is required on the rule as the issue lies with the session . When you directly send the request from your local system , the XG would receive the request and would forward the request to the remote system. Such reply would now follow back to XG appliance and would divert to your system directly as your Router in LAN network would not forward XG but to the system made the request . Such routing is Asymmetric routing and should be avoided as the reply would land on your system but from another device , in your case the router and your system would drop the packets .

    When you apply NAT MASQ the request to the Router is Natted with the LAN address of the XG appliance and the reply would land back to XG which is sent to your system . Which is a symmetric connection needed for a session based transfer. 

    Thanks and regards 

    Aditya Patel | Network and Security Engineer.

    Regards,

    Aditya Patel
    Global Escalation Support Engineer | Sophos Technical Support

    Knowledge Base  |  @SophosSupport | Sign up for SMS Alerts
    If a post solves your question use the 'This helped me' link.

  • The weird thing is that all other traffic is successfully routed to the remote network.  only port 443 traffic is not forwarded.

    I can ping the remote web server and connect via https without the masquerading policy enabled.

  • You can see in the packet capture that the Sophos Firewall forwards port 80 traffic, but does not forward Port 443 traffic

     

  • I came from Cyberoam...

    If the firewall acts as simple router from 10.0.20.0/24 to 192.168.99.0/24 you can use this:

    In console you can type:

    console> set advanced-firewall bypass-stateful-firewall-config add source_network 10.0.20.0  source_netmask 255.255.255.0

                   dest_network 192.168.99.0 dest_netmask 255.255.255.0

    and then:


    console> set advanced-firewall bypass-stateful-firewall-config add source_network 192.168.99.0  source_netmask 255.255.255.0

                 dest_network 100.20.0 dest_netmask 255.255.255.0

    with show advanced-firewall you can view settings..

    You can find a cyberoam document "How to Avercome Asymetric Routing" that explain this....

    ...It would be great for an official response Sophos XG. . .

    Bye