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

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

TLS packets not being passed on one link

Josh Sheehan

Hey there,

We've got a weird issue with one application failing because it looks like the XG isn't forwarding the TLS packets appropriately on one link.

A: XG135 (SFOS 19.0.1 MR-1-Build365)

10.109.10.250

B: XG330 (SFOS 19.0.1 MR-1-Build365)

10.100.25.19

Changes made:

- hostnames and IPs are already added to the exclusion lists

- Firewall rule is as close any / any between these two hosts as you can get.

- nothing in the logs to indicate that the packets are being dropped.

- all SSL/TLS inspections bypassed

- secondary link changed to primary via gateway manager

Packet captures at the ingress and egress ports on the XG135 show that TLSv1.2 initiation packets are not being passed on to the second link. Attached images show the end PC sending a 'Client Hello' packet and receiving a 'Server Hello' return when on the main link.. however, when changed to the secondary these packets are again sent to the XG135 but are not being egressed to the secondary MPLS link but just repeatedly being sent..(time stamps may be a little out, but trust me, it's the same every time)

EGRESS PRIMARY

SECONDARY

PC IN

XG EGRESS

Any help would be greatly appreciated



This thread was automatically locked due to age.
  • 0

    Sounds like a routing problem to me.

    We need to know a little more about your network topology and settings ar each peer.

    Mit freundlichem Gruß, best regards from Germany,

    Philipp Rusch

    New Vision GmbH, Germany
    Sophos Silver-Partner

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

  • 0 in reply to PhilippRusch

    Hey Philipp,

    I too suspected a routing issue, and have previously seen packets disappearing out the wrong interface.. our topology is pretty straight forward between these two.. they're a primary and backup.. so they share a lot of routes over 2 x MPLS links using iBGP.. to try and get this sorted I think their route tables are mirrored pretty much.. 

    To rule it out, I disabled and removed the primary link entirely so it only had one to choose from. 

    - No SD-WAN rules.  (I've tried on and off)

    - No static routes present  (again, tried on and off)

    I don't see anything in any captures, tcpdumps, or logs to show packets being dropped or rejected by the XG135.. it just seems to not want to pass on the Client Hellos.

    It's really got me stumped..

  • 0 in reply to Josh Sheehan

    Hi Josh,

    Hope you are well and thanks for reaching out to the community.

    With regards to "disappearing out the wrong interface" and probably a routing/network concern. May you check if there's any duplicate IP address/alias IP from other Interfaces? This resolved one issue I encountered in the past, I have done tcpdump, drppkt, packet capture and didn't find any drop/deny related logs because they are being forwarded to the alias IP then it is when I noticed that there is a duplicate alias IP bounded on an interface that is also being actively used by another WAN interface. If this would not be too much of a help, I may recommend you to open a support ticket to have this further check by an engineer especially if this impacts your network operations already.

    Hope this helps and thank you for choosing Sophos.

    Regards,

    Raphael Alganes
    Community Support Engineer | Sophos Technical Support
    Sophos Support Videos | Product Documentation  |  @SophosSupport  | Sign up for SMS Alerts
    If a post solves your question use the 'Verify Answer' link.

  • 0 in reply to Josh Sheehan

    Hello  

    If I understood it correct then here's your packet flow :

    10.109.10.250 -----> A: XG135 ======>MPLS=====>B: XG330-------> 10.100.25.19:443

    Are you observing this issue with 1 specific application or multiple applications/HTTPS traffic?
    Are you able to PING 10.100.25.19 from 10.109.10.250?
    Take packet capture for both PING(ICMP) & Port 443  on both appliance with capture string as "host 10.100.25.19" by navigating to  Diagnostics > Packet capture

    Also there is only SYN,ACK packets on above capture which has 1440 MSS, whats the MSS value for SYN packet? If the issue is with only one specific application then there are high chances for MSS mismatch as well.

    As recommended by   open support ticket to further investigate all possibilities.

    Hardik R 
    If a post solves your question use the 'Verify Answer' link.

  • 0 in reply to Hardik_R

    Cheers Hardik.. 

    You're correct, it's a single application issue.. which is why it's such a pain in the butt.. it's old software too.. I've tried advocating retiring it, but I'm sure we're all aware how much users don't like having their favourite toys taken away..

    I've looked into the MSS issue and forced both ends to have same MSS, but no change..

    I'm not sure how the packet capture on the appliance is different from running a wireshark on its outgoing interface? All packets show as being accepted and forwarded without issue, except without the additional detail of what kind of packet it is.. A policy test does the same thing..

    I'll log a ticket and see if we can get anywhere.. 

    Thanks for your assistance

    Josh

Unfiltered HTML