Juniper SRX: selectively disable TCP SYN or Sequence checking

SRX are stateful firewalls and will only allow traffic which matches an existing session. Sessions are created when a TCP SYN packet is received and it is permitted by the security policy. This of course means that the firewall needs to see both directions of a flow (client-server and server-client), otherwise these checks will block legitimate packets.
Whenever possible its best to ensure that asymmetric flows can't occur, but this is not always possible. Therefor you can disable these checks globally on the SRX:

set security flow tcp-session no-syn-check
set security flow tcp-session no-sequence-check

Obviously configuring this has a security impact and because it is a global option, it applies to all traffic flowing through the device. That's unfortunate as these checks typically only need to be enabled for a few policies. Luckily recent JunOS releases allow these checks to be enabled on a per-policy basis, like this:

policy trust-to-untrust {
    match {
        source-address any;
        destination-address any;
        application any;
    }
    then {
        permit {
            tcp-options {
                syn-check-required;
                sequence-check-required;
            }
        }
    }
}

The problem here is that Juniper implemented "syn-check-required" and "sequence-check-required" options instead of "no-syn-check-required" and "no-sequence-check-required" which would be a lot more usable in the real word. But because this is JunOS, there are ways around this of course. To disable TCP SYN or sequence checking on one policy while enabling it on all other policies, an apply-group can be used. The idea here is the following:

  1. Globally disable syn and sequence checking
  2. Using an apply-group to set "syn-check-required" and "sequence-check-required" on ALL security policies
  3. Using apply-groups-except to disable this apply-group on the few policies where syn or sequence checking is not desired

In JunOS code it looks like this:

groups {
    require_syn_seq_checking {
        security {
            policies {
                from-zone <*> to-zone <*> {
                    policy <*> {
                        then {
                            permit {
                                tcp-options {
                                    syn-check-required;
                                    sequence-check-required;
                                }
                            }
                        }
                    }
                }
            }
        }
    }
}
 
security {
    policies {
        apply-groups require_syn_seq_checking;
    }
}
 
security {
    policies {
	    from-zone foo to-zone bar {
		    policy one {
			    apply-groups-except require_syn_seq_checking;
                ...
			}
		}
	}
}

Hopefully Juniper will some day implement the "no-sequence-check" option at a per-policy level, but until then, this workaround can be used.

Juniper SRX: load-balancing based on source-ip

In a poor mans multi-homing setup, you may have a firewall with two ISP connections, each connection with its own IP space. This makes load-balancing a bit tricky. You can't just do per-session load balancing because that causes the clients public IP address to change at random. For some applications, that is not a problem, but there are many that lock a user to a specific IP. A common example are banking websites, as soon as the IP address changes, the user session is terminated.
An easy workaround would be to disable load-balancing for HTTP and HTTPS sessions, but nowadays that's most of the traffic.

In searching for a solution to this problem, I thought of a very easy workaround: load-balancing based on the clients (internal) IP address. This ensures that the same client always uses the same ISP connection, so the public IP address remains the same. Assuming a random distribution of the internal IP addresses, this should provide an even distribution of sessions between the two ISPs.

As it turns out, this can be done in JunOS quite easily. All it takes is a special use of subnet masks. Assuming you have two routing-instances, one for each ISP, the following firewall filter applied on the client-facing interface will distribute the traffic across the two connections. All clients whose IP address ends in an even number, are routed via ISP1 and clients whose IP address ends in an uneven number, are sent via ISP2.

firewall {
    family inet {
        filter source-based-lb {
            term even {
                from {
                    source-address {
                        10.32.0.0/255.255.0.1;
                    }
                }
                then {
                    routing-instance fbf-prefer-isp1;
                }
            }
            term odd {
                from {
                    source-address {
                        10.32.0.1/255.255.0.1;
                    }
                }
                then {
                    routing-instance fbf-prefer-isp2;
                }
            }
            term default {
                then accept;
            }
        }
    }
}

Of course, replace 10.32. with the users IP range. I tried using 0.0.0.0/0.0.0.1 and 0.0.0.1/0.0.0.1 in the firewall filter but that seems to trigger a bug in the junos CLI.

Using Time Domain Reflectometry (TDR) to locate cable faults on EX switches

One of the little known features of the Juniper EX switches is Time domain reflectometry which can be used to locate cable faults.
This is especially useful for long cables or when a connection is made up of multiple patch cables, to figure out where the cable is damaged.

To start TDR on a port, issue the following command:

request diagnostics tdr start interface <interface>

The test will take a couple seconds. To see the results, use:
show diagnostics tdr interface <interface>

On a working link, the result looks something like this:

Interface TDR detail:
Interface name                  : ge-1/0/26
Test status                     : Passed
Link status                     :  UP
MDI pair                        : 1-2
  Cable status                  : Normal
  Distance fault                : 0 Meters
  Polartiy swap                 : Normal
  Skew time                     : 0 ns
MDI pair                        : 3-6
  Cable status                  : Normal
  Distance fault                : 0 Meters
  Polartiy swap                 : Normal
  Skew time                     : 0 ns
MDI pair                        : 4-5
  Cable status                  : Normal
  Distance fault                : 0 Meters
  Polartiy swap                 : Normal
  Skew time                     : 8 ns
MDI pair                        : 7-8
  Cable status                  : Normal
  Distance fault                : 0 Meters
  Polartiy swap                 : Normal
  Skew time                     : 0 ns
Channel pair                    : 1
  Pair swap                     : MDIX
Channel pair                    : 2
  Pair swap                     : MDIX
Downshift                       : No Downshift

When something is wrong with the cable, the results may vary of course. A cable which simply isn't connected to anything at the far end shows up like this:

Interface TDR detail:
Interface name                  : ge-1/0/16
Test status                     : Passed
Link status                     : Down
MDI pair                        : 1-2
  Cable status                  : Open
  Distance fault                : 52 Meters
  Polartiy swap                 : N/A
  Skew time                     : N/A
MDI pair                        : 3-6
  Cable status                  : Open
  Distance fault                : 50 Meters
  Polartiy swap                 : N/A
  Skew time                     : N/A
MDI pair                        : 4-5
  Cable status                  : Open
  Distance fault                : 50 Meters
  Polartiy swap                 : N/A
  Skew time                     : N/A
MDI pair                        : 7-8
  Cable status                  : Open
  Distance fault                : 52 Meters
  Polartiy swap                 : N/A
  Skew time                     : N/A
Channel pair                    : 1
  Pair swap                     : N/A
Channel pair                    : 2
  Pair swap                     : N/A
Downshift                       : N/A

List of World IPv6 Day Resources

As everyone will already know by now, tomorrow is World IPv6 Day.

Below are a list of resources that may be useful.

Good luck everyone. Like most of Europe, I'll sleep through the first few hours of World IPv6 Day (as it starts at midnight UTC).

Blog Category:

Pages

Subscribe to Bart Jansens RSS Subscribe to Bart Jansens - All comments