Important note about SSL VPN compatibility for 20.0 MR1 with EoL SFOS versions and UTM9 OS. Learn more in the release notes.

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

Unable to connect to webinterface over ipsec site-to-site vpn

I've got an issue on two sophos xg125 (SFOS 17.5.9 MR-9). I can't access the webinterface over a ipsec site-to-site vpn (port 4444), but i can access all other devices over the vpn. It's possible to access the firewall with ssh over the vpn. HTTPS access on Administration -> Device Access for VPN is enabled. Furthermore i added a acl exeption rule, which allows HTTPS form the subnet i try to access and source zone vpn.

Here you can see the drop-packet-capture: 

2019-12-13 09:49:04 010202130 IP 172.31.151.75.46273 > X.X.X.X.4444 : proto TCP: F 3700840076:3700840076(0) win 513 checksum : 3150
0x0000: 4500 0028 4c94 4000 7f06 1da4 ac1f 974b E..(L.@........K
0x0010: 0a2c 4401 b4c1 115c dc96 568c 453f d16c .,D....\..V.E?.l
0x0020: 5011 0201 0c4e 0000 P....N..
Date=2019-12-13 Time=09:49:04 log_id=010202130 log_type=Firewall log_component=Invalid_Traffic log_subtype=Denied log_status=N/A log_priority=Alert duration=N/A in_dev= out_dev= inzone_id=0 outzone_id=0 source_mac= dest_mac= l3_protocol=P source_ip=X.X.X.X dest_ip=X.X.X.X l4_protocol=TCP source_port=46273 dest_port=4444 fw_rule_id=0 policytype=0 live_userid=0 userid=0 user_gp=0 ips_id=0 sslvpn_id=0 web_filter_id=0 hotspot_id=0 hotspotuser_id=0 hb_src=0 hb_dst=0dnat_done=0 proxy_flags=0 icap_id=0 app_filter_id=0 app_category_id=0 app_id=0 category_id=0 bandwidth_id=0 up_classid=0 dn_classid=0 source_nat_id=0 cluster_node=0 inmark=0x0 nfqueue=0 scanflags=0 gateway_offset=0 max_session_bytes=0 drp_fix=0 ctflags=0 connid=0 masterid=0 status=0 state=0 sent_pkts=N/A recv_pkts=N/A sent_bytes=N/A recv_bytes=N/A tran_src_ip=N/A tran_src_port=N/A tran_dst_ip=N/A tran_dst_port=N/A

2019-12-13 09:49:04 010202130 IP 172.31.151.75.46271 > X.X.X.X.4444 : proto TCP: F 1577518726:1577518726(0) win 513 checksum : 36206
0x0000: 4500 0028 4c93 4000 7f06 1da5 ac1f 974b E..(L.@........K
0x0010: 0a2c 4401 b4bf 115c 5e07 0686 9c5d c7c5 .,D....\^....]..
0x0020: 5011 0201 8d6e 0000 P....n..
Date=2019-12-13 Time=09:49:04 log_id=010202130 log_type=Firewall log_component=Invalid_Traffic log_subtype=Denied log_status=N/A log_priority=Alert duration=N/A in_dev= out_dev= inzone_id=0 outzone_id=0 source_mac= dest_mac= l3_protocol=P source_ip=X.X.X.X dest_ip=X.X:X.X l4_protocol=TCP source_port=46271 dest_port=4444 fw_rule_id=0 policytype=0 live_userid=0 userid=0 user_gp=0 ips_id=0 sslvpn_id=0 web_filter_id=0 hotspot_id=0 hotspotuser_id=0 hb_src=0 hb_dst=0dnat_done=0 proxy_flags=0 icap_id=0 app_filter_id=0 app_category_id=0 app_id=0 category_id=0 bandwidth_id=0 up_classid=0 dn_classid=0 source_nat_id=0 cluster_node=0 inmark=0x0 nfqueue=0 scanflags=0 gateway_offset=0 max_session_bytes=0 drp_fix=0 ctflags=0 connid=0 masterid=0 status=0 state=0 sent_pkts=N/A recv_pkts=N/A sent_bytes=N/A recv_bytes=N/A tran_src_ip=N/A tran_src_port=N/A tran_dst_ip=N/A tran_dst_port=N/A

 

Does someone has any idea how to solve this issue?



This thread was automatically locked due to age.
Parents
  • Hi Sandro,

    1) Administration Settings seems to be fine.

    2) The drops mentioned under drop packet capture are the finish packets and does not seem relevant.

    Can you please take the drop packet capture on the source private IP and the proto ICMP.


    Please ensure that LAN-VPN rule is without NAT on initiator end.

    3) Packet capture for the same timestamp would be appreciated.

    Regards,
    Resolution 24x7

  • Hi,

    Thank you for your reply.

    There is no NAT on either end of the vpn. Ping works fine over the vpn, there is no dropped package.

    If captured the communication on both ends on the port 4444

     

    Regards,

    Sandro

  • Hi Sandro,

    1) You may try refreshing mss once using the command below in advanced shell (Option "5" then Option "3)
     

    iptables -t mangle -I POSTROUTING -s 172.20.10.0/24 -d 10.10.0.0/16 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1460;


    Where,

    Source Network should be initiator network.
    Responder Network should be responder network.
    MSS should be configured as per the MSS of your WAN interface used in the IPSec Tunnel.

    First try on responder end then on initiator end.

    2) In case it does not help, reduce mss of the WAN interface on responder end used to establish the tunnel and also again for virtual VPN interface as in Point (1)

    Note : Recommend to take backup before the changes, as a precautionary measure.


    Regards,
    Resolution 24x7

  • Hi,

    Thanks for your fast reply.

    I refreshed mss on the responder end. It still doesn't work. I get the same droped packages. I cannot do it on  the initator end because it is on our datacenter. It would be to risiky and I don't think the problem lays there because the firewall in our datacenter has vpn connections to many sophos firwealls and all of them work fine (except those two).

    Regards,

    Sandro

  • Hi Sandro,

    1) Mss has to be reduced for  WAN of the responder and then of the LAN on responder.

    This helps in most scenarios to fix the issue.

    You can go as low as 1280. 

    If you have already reduced for WAN, then give a try for LAN.

    Note : Recommend to keep a backup and fluctuation can be expected for a minute.

    2) In case you cannot afford any downtime or fluctuation, then get the recommendation from the Sophos Technical Support Team once.


    Regards,
    Resolution 24x7

  • Hi,

    I set the mtu settings on the sender down to 1300, after that i was able to connect to the webinterface of the firewall. I found an old kb article in our knowlege base that this an known issue, but there is no solution for this issue.

    Thank you for your assistance.

    Regards,

    Sandro

  • Hi Sandro,


    Thank you for sharing the conclusive steps that worked.

    Thanks and Regards,
    Resolution 24x7

Reply Children
No Data