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,402 views \\ tags: CLI, Examples, stonegate firewall, Tips & Tricks

As you might have heard, Sun has recently released version 2.2 of its desktop virtualization solution: VirtualBox.

My curiosity was stimulated by the claimed support for the OVF standard, since this is the format we used in Stonesoft to create StoneGate Virtual Appliances when we went for VMWare certification.

Therefore today I tried to import a StoneGate Firewall/VPN Virtual Appliance made for VMware ESX in a fresh installation of VirtualBox on top of a Windows 2003 Server machine.

Result: it worked like a charm!

Although I haven’t tested extensively (like pushing a policy, processing traffic, etc.), installation and initial contact with a StoneGate Management Center worked smoothly.

This is of course not enough to ensure endorsement and official support from Stonesoft, but the purpose of my post is just to show you some screenshots about a successful test (in case you plan to run for a demo or test environment StoneGate Firewall/VPN Virtual Appliance within Sun VirtualBox 2.2).

Continue reading »

written by RoarinPenguin - 6,976 views \\ tags: stonegate firewall, test, virtualbox

Does your log browser become sometimes full of antispoofing and discard messages so that you don’t find any relevant information from the logs anymore. StoneGate Firewall/VPN 5.0 introduces a new feature that allows you to compress the antispoofing and discard messages per engine or per physical interface. You can find these settings from the Firewall engine properties dialog.

written by Tero Jantunen - 1,318 views \\ tags: 5.0, Features, stonegate, stonegate firewall

This restriction can be made for the whole engine or just for some physical interface of the engine. The engine can figure out the optimal values automatically or you can set custom values for the SYN flood restriction.

written by Tero Jantunen - 6,149 views \\ tags: 5.0, Features, SMC, stonegate, stonegate firewall

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,270 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,139 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,678 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,781 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 - 1,132 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 - 1,105 views \\ tags: CLI, engine, initial state, open port, state, stonegate firewall