StoneBlog.stonesoft.com

One of the features I use often, and especially in cases when there is some sort of trouble, is the ability to actually see what traffic passes the firewall.

Most admins don’t feel comfortable using the console (over ssh), and ofcourse it is not as trivial as it seems – especially remembering the exact commands. So, for the community, and for my own personal use, I’ll document a small issue I just had, and how I “solved” it.

A customer called, saying: “I use the StoneGate VPN to connect to my server with RDP, and all I get is a black screen”.  Now, that’s something that’s (unfortunately) not too uncommon. Google for “MTU”, “Path MTU Discovery” and “Black Hole Detection”, and you’ll get tons of info, which all come down to:

Single packets in ethernet networks have a maximum size of 1500 bytes (RFC 879). 1460 bytes of data + 40 bytes header (ip-addresses, ports, settings etc.). All tunneling protocols (VPN, PPTP,PPPoE, etc.) add some bytes to the header part. This means less room for the data part.

Both “client” and “server”  agree to send packets with max. 1460 bytes of data. The first few packets of the connection aren’t large, perhaps 1000 bytes max, and fit through perfectly. Client and server agree to communicate, draw a frame of the correct size, etc. Then however, comes the Windows Logo, a picture that is over 3000 bytes of size.  That means,  2  large packets are sent.  Somewhere on the connection from server to client, these packets do not fit. So, the picture the server sent, does not reach the client. A black screen of the wanted size just sits there, and waits… and waits…. and waits…..

Since I do not want to discuss what causes this,  but just want to know if it IS an MTU issue, I do following:

• check if both sides agree to use 1460 bytes of data
• reduce the packet size on either client or server side to 1310 bytes of data
• test whether RDP works again

Continue reading »

written by jebATpop-i - 3,394 views \\ tags: CLI, Examples, stonegate firewall, Tips & Tricks

Because of the read-only filesystem, you cannot modify /etc/motd file to show a customized message after each login. However, as there is only root account in the firewall engine, you can use the /data/home/root/.profile file for that purpose, as shown in the following example:

#!/bin/sh
echo
echo “WARNING: Unauthorized access to system is prohibited”
echo “and is subject to criminal and civil penalties.”
echo

written by christoph - 1,269 views \\ tags: CLI, customized, login message, stonegate firewall, tech details

You can enable autologout for StoneGate engine by adding the following line into /data/home/root/.profile file:

export TMOUT=300

The value is in seconds.

After you have edited the file, you need to logon again or give the same command on the shell to activate the setting.

It works if you are connected either with serial console and ssh console (if ssh enabled)

written by christoph - 1,138 views \\ tags: CLI, console, SSH, stonegate firewall, tech details

The arp cache timeout resides in

/proc/sys/net/ipv4/neigh/[DEV]/gc_stale_time

and the default value is 60 seconds.

The arp cache entries can be listed with ‘ip neighbor‘ command.

written by christoph - 2,673 views \\ tags: arp, CLI, stonegate firewall, timeout

“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 - 3,775 views \\ tags: arp, CLI, engine, state, state transitions, stonegate firewall, tech details

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 - 1,103 views \\ tags: CLI, engine, initial state, open port, state, stonegate firewall

This works on version 4.2.x and later.

Login to StoneGate firewall node and issue a following command:

vpninfo -S | grep login

If you want to know currently logged legacy ipsec vpn client (v.2.6.x) users issue a following command:

vpninfo -S | grep -A 10 login | grep -B 10 “UDP encap” | grep login

written by vm - 1,405 views \\ tags: CLI, mvpn client, stonegate firewall

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 - 1,935 views \\ tags: CLI, engine, rescue, revert policy

Small hint about routing and related queries in StoneGate.

For the CLI-aficionados who love to type

show ip route xxx.xxx.xxx.xxx

in their routers to troubleshoot routing, similar command exist in StoneGate:

ip route get xxx.xxx.xxx.xxx

However, simpler method exist in the GUI to right click on Firewall in Info Panel – Routing Tab and select Query Route  as shown below: easier, cleaner, better!

written by RoarinPenguin - 1,744 views \\ tags: CLI, GUI, hint, routing