Apr 04

…don’t miss the sixth episode of The Adventures of Antti Pilvinen, which has just been published ;)

Happy reading,

The RoarinPenguin

written by RoarinPenguin - 774 views \\ tags: , ,

Oct 29

StoneGate FW/VPN IPsec Certificate Interoperability

Firewall Engine, VPN -
1 Star2 Stars3 Stars4 Stars5 Stars (4 votes, average: 4.25 out of 5)
Loading ... Loading ...
No Comments »

VPN Consortium (VPNC) recently started to test IPsec VPN product interoperability against a new criteria. The test is about VPN interoperability when tunnel setup is authenticated using certificates from a common trusted certificate authority.

In October 2010 VPNC update first results were announced. StoneGate Firewall/VPN was among the first five vendors to pass this test and receive right to use this new logo.

VPNC Certificate Interop Certified

As a VPN technology this is nothing new for StoneGate FW’s IPsec VPN. It has supported certificate based VPN authentication starting from the very first version.

written by juhalu - 1,201 views \\ tags:

Jun 28

In many environments Network Address Translation (NAT) seems to be very extensively used. That has resulted in hundreds or even thousands of NAT rules in Firewall Policies. To help managing all these NAT rules, we have now introduce two nice features that you may have already used in Access Rules side.

Continue reading »

written by Tero Jantunen - 1,486 views \\ tags: , , , , , , , , , , ,

Jun 25
Administrators can now limit the number of connections to a service per source and/or destination IP. This limit is configured in FW Access Rules. Just select Permit as action, open the Action Options dialog and use these new settings there:

Connection limiting


Connection limiting

The limits are valid per Source or Destination address. So if there are multiple Source or Destination addresses used in the policy, the limit applies to all of them separately. As you can see from the snapshot above, you can limit the connections by source and destination simultaneously.

written by Tero Jantunen - 918 views \\ tags: , , , , , , , ,

Jun 21

In StoneGate Management Center 5.2 the VPN troubleshooting tools have improved significantly. There are a lot of new drill-in actions available in System Status view. You can for example right-click any VPN tunnel in the VPN diagrams and drill-in to logs that flow through the selected tunnel. You can also right-click individual Gateways or Endpoints (from the Info panel) and drill-in to the related logs.

Drill in to VPN log data

written by Tero Jantunen - 1,796 views \\ tags: , , , , , , , , ,

Jun 18

StoneGate 5.2 – IGMP Proxy

Feature Previews, Firewall Engine, SMC -
1 Star2 Stars3 Stars4 Stars5 Stars (3 votes, average: 4.00 out of 5)
Loading ... Loading ...
No Comments »

StoneGate Firewall 5.2 supports now multicast routing through IGMP proxy. This new configuration option enables the most useful method to support “dynamic” multicast routing (defined in RFC 4605). Multicast Routing is now configured from the dialog that can be launced from the Interfaces tab in Firewall properties. Please note that IGMP proxy and Static Multicast Routing can not be used simultaneously.

IGMP Proxy

written by Tero Jantunen - 1,380 views \\ tags: , , , , ,

May 31

During the last two years we have received feedback from Gartner as well as some customers that StoneGate IPS is surely efficient but it is a bit difficult to configure inspection rules for the device. The other feedback we have noticed in customer interviews is that administrators are not aware of all StoneGate’s inspection capabilities. Administrators don’t seem to have time to configure and manage Inspection rules as granular way as for managing the FW access rules.

In StoneGate 5.2 we have now answered your needs. There is a brand new way of configuring inspection rules with the help of a new Inspection Rules panel. Read more how to configure the Inspection rules with SMC 5.2.

Continue reading »

written by Tero Jantunen - 1,391 views \\ tags: , , , , , , , , ,

May 28

Link aggregation or “network interface bonding” in linux terms, means a standard way to aggregate multiple physical network interfaces as a one. StoneGate firewalls will have a support for aggregated interfaces starting from version 5.2.

Link Aggregation

Continue reading »

written by Tero Jantunen - 1,450 views \\ tags: , , , , , , ,

May 24

StoneGate 5.2 – IPv6 support for FW

Feature Previews, Firewall Engine, SMC -
1 Star2 Stars3 Stars4 Stars5 Stars (3 votes, average: 4.00 out of 5)
Loading ... Loading ...
2 Comments »
IPv6 support for StoneGate IPS was introduced already a couple of years ago in StoneGate 4.3. IPv6 support has now been extended to cover also Firewalls. You can now use IPv6 addresses in FW interface configuration, configure IPv6 Routing and define the IPv6 Access Policy with the help of IPv6 hosts and, networks and address ranges. IPv6 is supported now also for Firewalls

There are still some remaining tasks related to IPv6 support. Those include support for IPv6 clustering, IPv6 protocol agents and IPv6 NAT policies. These remaining enhancements are already in StoneGate roadmap and currently scheduled to version 5.3 (Q1/2011).

written by Tero Jantunen - 2,108 views \\ tags: , , , ,

Mar 23

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,845 views \\ tags: , , ,