StoneBlog.stonesoft.com

“Neighbour table overflow” message comes from linux kernel and means that ARP cache overflows. This may happen if there are a lot of directly connected hosts behind firewall’s interface.

It is possible to increase the size of engine’s ARP cache by changing values of
/proc/sys/net/ipv4/neigh/default/gc_thresh3 (The hard maximum number of entries to keep in the ARP cache. Defaults to 1024.) and
/proc/sys/net/ipv4/neigh/default/gc_thresh2 (The soft maximum number of entries to keep in the ARP cache. Defaults to 512.)

The changes should be made to /data/run-at-boot (remember Firewall state transitions) file in order for changes to survive boot. The run-at-boot file must be created with execute permission for root.

Add the following lines to /data/run-at-boot file in all of the engines of the cluster:

#!/bin/sh
echo 8192 >/proc/sys/net/ipv4/neigh/default/gc_thresh3
echo 4096 >/proc/sys/net/ipv4/neigh/default/gc_thresh2

The change activates after boot or by executing the run-at-boot script. The change should be activated as simultaneously as possible in all the nodes of the cluster, so that the functioning of the nodes in the cluster would be same all the time.

written by christoph - 1,579 views \\ tags: arp, CLI, engine, state, state transitions, stonegate firewall, tech details

The refuse action behaves differently depending on the protocol in rule:

• For TCP packets (with any combination of flags), a TCP Reset packet is sent with proper port and sequence number settings.

• For UDP packets, an ICMP Port Unreachable (Type 3, Code 3) is sent with the eight first bytes copied from the original IP packet (exactly like they appear) in the payload.

• For ICMP packets, no responses are sent at all. This is treated like a ‘discard’ action would be used.

• For any other type of IP packets, an ICMP Protocol Unreachable (Type 3, Code 2) is sent with the eight first bytes copied from the original IP packet (exactly like they appear) in the payload.

written by christoph - 663 views \\ tags: action, engine, Policy, refuse, stonegate firewall

In initial configuration state (before any security policies have been installed from the management), the following connections are allowed by the firewall engine:

From the firewall engine:
- SSH (TCP/22)
- SG-init (TCP/3021)

To the firewall engine:
- SG-remote-upgrade (TCP/4950)
- SG-mgmt (TCP/4987)
- SG-monitor (TCP/8888)
- SSH (TCP/22)

Furthermore, the following ICMP messages are allowed to and from the firewall engine:
- Echo reply ( type 0 )
- Echo ( type 8 )
- Destination unreachable, fragmentation needed and don’t fragment was set ( type 3, code 4 )

written by christoph - 639 views \\ tags: CLI, engine, initial state, open port, state, stonegate firewall

If there is a link with a smaller MTU somewhere between the VPN gateways, the router connected to the link will send ICMP fragmentation needed message (type 3, code 4) as a response to ESP packets that have DF bit set and that are bigger than the MTU.

However, only the MTU information is stored on the firewall at that time but no ICMP error message is sent to the endpoint of the original connection.

When the host in the internal network sends the following packet, that’s when the firewall handling the connection will reply with the ICMP error message.

written by RoarinPenguin - 1,865 views \\ tags: engine, fragmentation needed, ICMP, VPN

From the StoneBlog Admin Team: the procedure described here carries a high risk and can harm your system if performed incorrectly.
We do not recommend following this procedure unless you are an expert with StoneGate and other related technology. Stonesoft’s Support does not provide assistance with any problems that you may encounter as a result of following this procedure.

If you have disabled Policy Handshake feature from firewall properties and you install a policy that breaks management communication, you need to manually revert to previous configuration from StoneGate firewall node locally.

You can do this with command

/usr/lib/stonegate/bin/sgcfg -a -d /data/config/policy/previous apply

This needs to be run on all cluster nodes, ad of course it works only if a previous policy exists on given node

There is also more “standard” way to revert to previous policy from the GUI using a snapshot.

written by RoarinPenguin - 891 views \\ tags: CLI, engine, rescue, revert policy