https-proxy-server: sni check results in broken tls

vanessa

hi community,
i'm using a simple https-proxy policy for inbound connections and only check for the correct sni. the firebox accepts the client hello with valid sni, routes it to the destination. so far so good. when the server response with a valid "server hello, change cipher spec and appdata" packet, then the firebox cuts it without any statement. sometimes in the beginning and sometimes at the end of the packet. the handshake fails and the server resets the connection. the clue is, that its only cutting the server hello packet when the client hello comes from remote site-to-site client (ikev2). when i try the exact same request, hitting the exact same rule from a sslvpn client, then the firebox doesn't touch the packet at all.
what could cause this behavior? the logs all look valid, no errors, drops, blocks or whatever. when i build the policy as a filter then it works. so for sure its the https-proxy engine which intercepts the tls handshake. but why?! i'm not doing tls inspection, only sni check.
what is going on here? i would expect the firebox to drop the packet, but cutting it? thats really strange.. any ideas? ^^
kind regards,
vanessa

Bruce_Briggs

For the record, what firewall model do you have and what Fireware version is it running?

james.carson

Hi @vanessa
I'm not sure exactly what you mean by cutting it. I'm assuming you mean fragmenting the packet?

Depending on your settings for IKEv2 and SSLVPN, the portion of the packet for the payload might be smaller for IKEv2. If whatever you're using is trying to send a full 1500 byte packet, the firewall may be breaking (or trying to break it) up.

If a user is coming in via IKEv2 or SSLVPN, please make sure whatever policy you're trying to use on the firewall has "IKEv2_Users" or "SSLVPN_Users" as the from group, or those users will likely not be able to access that policy.

vanessa

Hi, thx for your replys.
Model: M5800
Current Version: 12.11.2 (Build 713726)

I really mean cutting, sometimes the beginning of the packet is missing and sometimes the end (seen in wireshark tcp stream) I thought about mtu too and already take care for mss 1300 on the webserver, the server response has a size of 1280byte.
And its not that the policy is not working, it hits, accepts and forwards correctly from source (ikev2 or sslvpn) to destination (internal webserver). its only the way back, the response of the webserver to the client hello which is treaded differently from the firebox, but the content of the packet is the same. same tls version, same cert-chain etc. the ikev2 remote client gets the response as a broken server hello and the sslvpn client receives it as originally sent by the server.
When I reconfigure the policy from https-proxy to portfilter only, then it works for ikev2 too. Thats why I thought its the https-proxy and the firebox is somehow modifying the packet..

james.carson

@vanessa I would suggest a support case for this -- you can open a support case via the support center button at the top right of this page.