StoneBlog.stonesoft.com

Generally we want or it is mandatory to use the Virtual IP feature with the Stonegate VPN client. But the Virtual IP needs to configure DHCP relay to give an IP to the remote VPN client.

So to clarify the situation about this topic, granting virtual address for client changed in version 4.2.0 and new changes were introduced in FW 4.2.6.

You will see below some description to help you in configuration and understanding of this DHCP part.

Continue reading »

written by Hokkyokuguma - 2,388 views \\ tags: DHCP, mvpn client, tech details, Tips & Tricks, Virtual IP

I recently wrote about clustered FW/IPS installations and in that discussion a question was raised about the bypass functionality of the IPS appliances.  So, let’s have a look.
Continue reading »

written by olli - 5,473 views \\ tags: IPS, tech details

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

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

Traffic is balanced proportionally between the netlinks using measured throughput and packet success rate as a criteria for link performance.

The measurement is based on lazy acknowledgements, i.e. receiving end tells the sender how many packets it has received during the last second (if there is any traffic).

The link selection is also made as stable as possible because some properties of IPSec VPN. Link is changed only if its performance drops below a fixed threshold value.

If performance goes under threshold (128) then standby activation counter is increased. This performance check is done when packet arrives to multi-link VPN module and certain time (about 1 sec) has elapsed. If counter value is greater than 2 then link is marked offline.

Therefore a fail-over from one link to another takes usually 8-12 seconds if one link fails totally.

Measuring of RTT is not done for feasibility reasons, since the load on the other end also affects the measurement. That measurement would also require some kind of periodical query – response mechanism.

It’s probably not possible to compensate for network jitter using multiple links at all; that would require being able to somehow “forecast” the changes in RTT.

Multi-link VPN provides availability in case an ISP connection fails, but is not able to guarantee QoS.

Roar!

written by RoarinPenguin - 1,453 views \\ tags: measurement, MultiLink VPN, tech details