SonicWALL firewall internal packet flow

I've worked with SonicWALL firewalls for over 10 years in hundreds of different installations. In order to understand how a firewall handles traffic, it helps to know how traffic is treated interally. For example it helps to know if the nat engine is traversed before the policy check or after, in order to configure the nat-policy and the access rules correclty.

Since generation 5 SonicWALL firewalls use cavium octeon cpus and they process everthing in cpu. This is a strength and a weakness of the firewall, after it can treat traffic very dynamically and using software-updates the handling of the traffic can be changed. However compared to for example asic processor architecture the performance usually is lower. So there are pros and cons.

The SonicWALL firewall internal packet flow looks like the following:

 Packet fragmentation is handled as follows:

The packet capture feature can be helpful to understand the packet flow. However in rare cases it can mislead you after it is not 100% accurate when facing bugs in SonicOS:
https://www.sonicwall.com/en-us/support/knowledge-base/170513143911627

FortiGate Path MTU Discovery

FortiOS PMTU Cmd

FortiOS supports RFC 1191 "Path MTU Discovery IPv4" and RFC 1981 (PMTU IPv6), a technique for dynamically discovering the maximum transmission unit (MTU) of an arbitrary internet path.

It can be checked using the following command, which lists the routing cache:

diag ip rtcache list
 
Example output:

FGT51E3U00000000 # c v
FGT51E3U00000000 (vdom) # edit root
current vf=root:0

FGT51E3U00000000 (root) # diag ip rtcache list

family=02 tab=254 vf=0 type=01 tos=0 flag=00000200
1.2.3.4@0->192.168.117.15@18(LAN-HardwSwitch) gwy=192.168.1.1 prefsrc=0.0.0.0
ci: ref=0 lastused=199 expire=0 err=00000000 used=3 br=0 pmtu=1500

family=02 tab=254 vf=0 type=01 tos=0 flag=04000200
192.168.1.1@18(LAN-HardwSwitch)->194.1.2.3@4(wan1) gwy=192.168.0.1 prefsrc=192.168.1.254
ci: ref=1 lastused=159 expire=0 err=00000000 used=0 br=0 pmtu=1500

family=02 tab=254 vf=0 type=01 tos=0 flag=04000200
192.168.1.1@18(LAN-HardwSwitch)->194.1.2.3@4(wan1) gwy=192.168.0.1 prefsrc=192.168.1.254
ci: ref=1 lastused=4 expire=0 err=00000000 used=0 br=0 pmtu=1500

family=02 tab=254 vf=0 type=01 tos=0 flag=00000200
148.0.0.1@0->192.168.1.1@18(LAN-HardwSwitch) gwy=0.0.0.0 prefsrc=0.0.0.0
ci: ref=0 lastused=239 expire=0 err=00000000 used=24 br=0 pmtu=1500

family=02 tab=254 vf=0 type=01 tos=0 flag=00000200
104.1.2.3@0->192.168.1.1@18(LAN-HardwSwitch) gwy=0.0.0.0 prefsrc=0.0.0.0
ci: ref=0 lastused=626 expire=0 err=00000000 used=3 br=0 pmtu=1500

family=02 tab=254 vf=0 type=01 tos=0 flag=00000200
192.168.1.1@0->104.2.3.4@4(wan1) gwy=192.168.0.1 prefsrc=0.0.0.0
ci: ref=0 lastused=441 expire=0 err=00000000 used=2 br=0 pmtu=1500
 
family=02 tab=254 vf=0 type=01 tos=0 flag=04000200
192.168.1.1@18(LAN-HardwSwitch)->170.1.2.3@4(wan1) gwy=192.168.0.1 prefsrc=192.168.1.254
ci: ref=4 lastused=14 expire=0 err=00000000 used=2 br=0 pmtu=1500

What is Path MTU Discovery? 

Wikipedia:

Path MTU Discovery (PMTUD) is a standardized technique in computer networking for determining the maximum transmission unit (MTU) size on the network path between two Internet Protocol (IP) hosts, usually with the goal of avoiding IP fragmentation. PMTUD was originally intended for routers in Internet Protocol Version 4 (IPv4).^[1] However, all modern operating systems use it on endpoints. In IPv6, this function has been explicitly delegated to the end points of a communications session.

General hints:

• Please do not mix up layer 2 ethernet frame size and layer 3 ip mtu paket size. If you want to use for example jumbo-frames you have to change both, the l2 ethernet frame size at your switches/network devices and l3 ip mtu size at you routers/firewall/network devices.
• For testing MTU do not relay on checking if google is available or RDP-connections are working. Both and many more applications/services use techniques to overcome wrong frame-size/mtu-size implementations.
• When having issues with packets over virtual tunnels like for example IPSec or when setting up new interfaces/links or when using dynamic routing protocols like OSPF or BGP, checking the mtu is always a good idea.