wan, vlan, tagged, untagged

My router is temporarily far from my firebox. They are separated by a couple of managed switches.
I need help on how to configure the external interface of the firebox.
The router sends untagged traffic to port1[untagged with pvid 29] on switch1.
Switch1 and switch2 are in trunk with a tagged port each one, for vlan 29 and others.
How do I configure switch2 egress port linked to my firebox external interface eth1?
A) switch2 egress tagged for 29 and firebox eth1 configured as vlan type added to vlan 29.
B) switch2 egress untagged with pvid 29, firebox' eth1 untagged and configured as external.

Comments

  • I would match what the router is sending: untagged with pvid 29 configured as external

    Then when the router is connected directly to the firewall external interface - nothing needs to be changed on the firewall.

  • @Bruce_Briggs said:
    I would match what the router is sending: untagged with pvid 29 configured as external

    Then when the router is connected directly to the firewall external interface - nothing needs to be changed on the firewall.

    Thank you Bruce, solution B is working.
    I had to disable my https proxy lan to external: many sites were loading eternally if it was on, especially after authenticating. Any idea?

  • it seems to be a problem of handshake

  • We need more details.
    Any Traffic Monitor entries to help understand this ?

  • I have an Invalid connection state and connection failed, Unhandled External Packet-00. xxx is lan, yyy is target site, zzz wan connection through vlan

    2021-08-03 16:43:27 Allow 89.0.0.xxx yyy.167.246.67 http/tcp 49474 80 LAN WAN zzz.3.100.34 ProxyAllow: HTTP header match (HTTP-proxy-00) HTTP Proxy Profile proc_id="http-proxy" rc="590" msg_id="1AFF-001B" proxy_act="HTTP Proxy Profile" rule_name="Default" header="Cookie: _CULTURE_ID=it-IT; ASP.NET_SESSIONID=0yfvglouxwywvsv0svluzfgq; X19GB3JNZXJ5=G1tGGxyPNZfAAMFDAylifk1eAC-10ixQnOqGaSEJl2jB2kRBBPeFMrzGp0niLo5XLg61mYJsJ3qSiPxbk5jjtaCQ-M51" geo_src="DEU" geo_dst="ITA" Traffic
    2021-08-03 16:43:28 http-proxy 0xc8df40-19687 13164352:19687: nondata_event: DATA_INTERNAL(234): 57: 89.0.0.xxx:49474 -> yyy.167.246.67:80 [A t] {X} Debug
    2021-08-03 16:43:28 Allow 89.0.0.xxx yyy.167.246.67 http/tcp 49474 80 LAN WAN zzz.3.100.34 ProxyAllow: HTTP Request categories (HTTP-proxy-00) HTTP Proxy Profile proc_id="http-proxy" rc="590" msg_id="1AFF-0021" proxy_act="HTTP Proxy Profile" cats="Business and Economy" op="GET" dstname="ater-pub.siavcloud.com" arg="/InteractiveDashboard" action="Web Blocker Profile 01.1" geo_src="DEU" geo_dst="ITA" Traffic
    2021-08-03 16:43:31 http-proxy 0xc8df40-19687 13164352:19687: nondata_event: DATA_INTERNAL(46): 57: 89.0.0.xxx:49474 -> zzz.167.246.67:80 [A] {B} Debug

    2021-08-03 16:47:47 pxy 0x2ea7060-56288 connect failed Connection timed out 66: 89.0.0.xxx:55451 -> yyy.167.246.67:80 [A] {B} | 70: zzz.3.100.34:55451 -> yyy.167.246.67:80 [!B c] {B}[P] Debug
    2021-08-03 16:47:47 http-proxy 0x2ea7060-56288 48918624:56288: nondata_event: FAILED_CHAN_B: 70: zzz.3.100.34:55451 -> yyy.167.246.67:80 [!B fc] {B} Debug
    2021-08-03 16:47:48 Allow 89.0.0.xxx yyy.167.246.67 http/tcp 56370 80 LAN WAN zzz.3.100.34 ProxyAllow: HTTP header match (HTTP-proxy-00) HTTP Proxy Profile proc_id="http-proxy" rc="590" msg_id="1AFF-001B" proxy_act="HTTP Proxy Profile" rule_name="Default" header="Cookie: _CULTURE_ID=it-IT; ASP.NET_SESSIONID=0yfvglouxwywvsv0svluzfgq; X19GB3JNZXJ5=G1tGGxyPNZfAAMFDAylifk1eAC-10ixQnOqGaSEJl2jB2kRBBPeFMrzGp0niLo5XLg61mYJsJ3qSiPxbk5jjtaCQ-5i5vBv4e61Zqerbu4A1; USER=eerXjOmhOHDlGJuOOxPpQhYlFMimC5qAqf8YusQjz0d07tgOS5oGHpVc+ /bOL8S2U0FDX/GsNIU2XmoHWhl3ha9UZhhrBIrzGfGhvVsua25fcWAlkj/vhPIanR/2g9CmQ3rLWe17hgk+yidlEOddpXlwchBIvIuxK1oJzVStxxyM51" geo_src="DEU" geo_dst="ITA" Traffic
    2021-08-03 16:47:48 http-proxy 0x47cf380-56341 75297664:56341: nondata_event: DATA_INTERNAL(234): 53: 89.0.0.xxx:56370 -> yyy.167.246.67:80 [A t] {X} Debug

    2021-08-03 16:52:12 Deny yyy.167.247.67 zzz.3.100.34 45691/tcp 443 45691 WAN zzz.3.100.34 Firebox Denied 40 53 (Unhandled External Packet-00) proc_id="firewall" rc="101" msg_id="3000-0148" tcp_info="offset 5 A 1539744256 win 3585" geo_src="ITA" geo_dst="ITA" Traffic

    2021-08-03 16:52:15 Allow 89.0.0.175 yyy.167.246.67 https/tcp 59393 443 LAN WAN zzz.3.100.34 Application identified 40 52 (Any_OUT_LAN_ATER-00) proc_id="firewall" rc="100" msg_id="3000-0149" src_ip_nat="zzz.3.100.34" tcp_info="offset 5 AF 459853465 win 24844" app_id="65535" app_name="unknown" app_cat_id="255" app_cat_name="unknown" app_beh_id="255" app_beh_name="unknown" action="Global" sig_vers="18.163" src_user="[email protected]" route_type="SD-WAN" geo_src="DEU" geo_dst="ITA" Traffic
    2021-08-03 16:52:20 https-proxy 0x34da850-88314 55421008:88314: nondata event 'SSL_PROTO_CLIENT_HELLO_COMPLETE: 81: 89.0.0.xxx:58475 -> yyy.167.246.67:443 [A t] {B}' Debug
    2021-08-03 16:52:20 https-proxy 0x34da850-88314 55421008:88314: nondata event 'CONNECTED_CHAN_B: 82: zzz.3.100.34:58475 -> yyy.167.246.67:443 [B t] {X}' Debug
    2021-08-03 16:52:20 https-proxy 0x34da850-88314 82: zzz.3.100.34:58475 -> yyy.167.246.67:443 [B t] {N}: connected with TLSv1.3 (0x304) Debug
    2021-08-03 16:52:20 https-proxy 0x34da850-88314 55421008:88314: nondata event 'SSL_CONNECTED: 82: zzz.3.100.34:58475 -> yyy.167.246.67:443 [B t] {N}' Debug
    2021-08-03 16:52:20 https-proxy 0x34da850-88314 55421008:88314: nondata event 'CONNECTED_CHAN_B: 82: zzz.3.100.34:43507 -> yyy.167.246.67:443 [B t] {N}' Debug
    2021-08-03 16:52:25 Deny 89.0.0.xxx yyy.167.246.67 https/tcp 55457 443 LAN Firebox tcp invalid connection state 40 128 (Internal Policy) proc_id="firewall" rc="101" msg_id="3000-0148" tcp_info="offset 5 AF 2847143537 win 258" src_user="…@..." Traffic

    2021-08-03 16:54:26 Deny yyy.167.246.67 zzz.3.100.34 43507/tcp 443 43507 WAN zzz.3.100.34 Firebox tcp invalid connection state 40 53 (Internal Policy) proc_id="firewall" rc="101" msg_id="3000-0148" tcp_info="offset 5 AF 2081975249 win 7681" Traffic

    2021-08-03 16:55:56 Allow 89.0.0xxx. yyy.167.246.67 https/tcp 56929 443 LAN WAN zzz.3.100.34 HTTPS Request (HTTPS-proxy._FRAN_TEST-00) HTTPS-Client.Standard proc_id="https-proxy" rc="548" msg_id="2CFF-0000" proxy_act="HTTPS-Client.Standard" tls_profile="TLS-Client-HTTPS.Standard" tls_version="TLS_V13" sni="ater-pub.siavcloud.com" cn="*.siavcloud.com" cert_issuer="CN=DigiCert TLS RSA SHA256 2020 CA1,O=DigiCert Inc,C=US" cert_subject="CN=*.siavcloud.com,O=Siav S.p.A.,L=Rubano,ST=Veneto,C=IT" action="allow" app_id="0" app_cat_id="0" sig_vers="18.163" sent_bytes="3110" rcvd_bytes="7267" geo_src="DEU" geo_dst="ITA" Traffic
    2021-08-03 16:55:56 https-proxy 0x12c6f60-19803 19689312:19803: nondata event 'SSL_PROTO_CLIENT_HELLO_COMPLETE: 49: 89.0.0xxx.:56952 -> yyy.167.246.67:443 [A t] {B}' Debug
    2021-08-03 16:55:56 https-proxy 0x12c6f60-19803 19689312:19803: nondata event 'CONNECTED_CHAN_B: 50: zzz.3.100.34:56952 -> yyy.167.246.67:443 [B t] {X}' Debug
    2021-08-03 16:55:56 https-proxy 0x12c6f60-19803 50: zzz.3.100.34:56952 -> yyy.167.246.67:443 [B t] {N}: connected with TLSv1.3 (0x304) Debug
    2021-08-03 16:55:56 https-proxy 0x12c6f60-19803 19689312:19803: nondata event 'SSL_CONNECTED: 50: zzz.3.100.34:56952 -> yyy.167.246.67:443 [B t] {N}' Debug
    2021-08-03 16:55:56 https-proxy 0x12c6f60-19803 19689312:19803: nondata event 'CONNECTED_CHAN_B: 50: zzz.3.100.34:35399 -> yyy.167.246.67:443 [B t] {N}' Debug
    2021-08-03 16:55:57 Deny yyy.167.246.67 zzz.3.100.34 34987/tcp 443 34987 WAN zzz.3.100.34 Firebox Denied 40 53 (Unhandled External Packet-00) proc_id="firewall" rc="101" msg_id="3000-0148" tcp_info="offset 5 A 755900923 win 65024" geo_src="ITA" geo_dst="ITA" Traffic

  • I had to disable tcp syn for i had a lot of errors

  • james.carsonjames.carson Moderator, WatchGuard Representative

    TCP invalid connection state and syn check suggest that you're not receiving all of the connection to the firewall. Is there anything in front of or behind the firewall that might be dropping some/all of the connection?

    Turning off TCP SYN check in the firewall stops the firewall from dropping the traffic it doesn't have a connection table entry for, but it doesn't do anything to fix the underlying problem. If you're still missing part of the connection's traffic, the destination equipment still might not have useable traffic.

    -James Carson
    WatchGuard Customer Support

  • Perhaps a speed/duplex on one of you upstream connection on on Firebox External?

    In WSM Firebox System Manager -> Status Report, Interfaces section, you can look at the stats on your external interface to see if you have a bunch of errors or collisions - which usually indicates a speed/duplex issue on that interface.

  • @Bruce_Briggs said:
    Perhaps a speed/duplex on one of you upstream connection on on Firebox External?

    In WSM Firebox System Manager -> Status Report, Interfaces section, you can look at the stats on your external interface to see if you have a bunch of errors or collisions - which usually indicates a speed/duplex issue on that interface.

    RX packets:44729205 errors:0 dropped:0 overruns:0 frame:0
    TX packets:17571918 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:1000

  • @James_Carson said:
    TCP invalid connection state and syn check suggest that you're not receiving all of the connection to the firewall. Is there anything in front of or behind the firewall that might be dropping some/all of the connection?

    Turning off TCP SYN check in the firewall stops the firewall from dropping the traffic it doesn't have a connection table entry for, but it doesn't do anything to fix the underlying problem. If you're still missing part of the connection's traffic, the destination equipment still might not have useable traffic.

    I double checked the path of the vlan and there are no collisions or misconfigurations.
    One switch has the vlan running on a 10gb fiber link instead of 1gb utp like the rest

  • After sorting out some network problem, the last one that remains is:
    2021-08-05 14:42:05 https-proxy 0x8afa40-4454 9108032:4454: nondata event 'CHAN_READ_BLOCKED: 45: 89.0.0.154:51164 -> 217.61.8.49:443 [A txr] {B }' Debug
    After ssl HELLO and ssl CLOSE.
    Taking down the HTTPS Proxy solves the problem

  • Do you know the domain being accessed here?

    Some sites don't work using the HTTPS proxy and need to use a HTTPS packet filter to be accessed.

  • it turns out to be an issue of solution B on my first post, as connecting directly to the router has no issue. Will try changing the network topology and give you an update

  • https://i.ibb.co/f8M4m4n/Cattura.jpg
    This is my network, the issue is between wg https proxy and wan over vlan

  • edited August 10

    Solved! It was trivially an MTU problem.
    No errors or collisions, but fragmentation!
    ping www.yahoo.com -f -l 1464 and I found out the optimal MTU to set on the external interface.

Sign In to comment.