…don’t miss the sixth episode of The Adventures of Antti Pilvinen, which has just been published
Happy reading,
The RoarinPenguin
…don’t miss the sixth episode of The Adventures of Antti Pilvinen, which has just been published
Happy reading,
The RoarinPenguin
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.
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.
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.
| 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: |
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.
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.
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.
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.
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.
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).
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:
Recent Comments