[AusNOG] Application Firewall Recommendations

[Tony]

The issue is it's not supported by the underlying BSD packet-filter code (ie. the "pf" part of the name). Normal "linux" has this built into it I believe and uses the GRE session ID to keep a state table of PPTP sessions, eg:

=====
the older PPTP patch does NOT support masquerading
of multiple PPTP clients attempting to access the same PPTP
server. If you're trying to do this, you should take a look at your network
design and consider whether you should set up a PPTP router for your local
clients. The 2.0 patch incorporates Call-ID masquerading, which allows
multiple simultaneous sessions.

=====

Plenty of firewall DO allow multiple outbound PPTP to the same server IP, just not pfSense. When we evaluated it several years ago as a replacement for SnapGear's we tested that PPTP worked inbound and outbound (and even at the same time), we just never thought to test multiple outbound to the same server.


Would be nice to be able to NAT each internal client to their own public IP address, but I'm sure you can see the problem there :)
Bring on IPv6 to solve this as well I guess to remove the restrictions related to NAT and only having a limited number of public IP addresses available (typically a /29 for the locations we have pfsense installs).


In regard to using something more secure, yes for inbound connectivity we are typically using OpenVPN, the problem is connecting outbound to places that we have no influence over and are still using PPTP with no chance of changing any time soon.



regards,
Tony.





>________________________________
> From: Damien Gardner Jnr <rendrag at rendrag.net>
>To: Tony <td_miles at yahoo.com> 
>Cc: Joshua D'Alton <joshua at railgun.com.au>; Alex Samad - Yieldbroker <Alex.Samad at yieldbroker.com>; "ausnog at lists.ausnog.net" <ausnog at lists.ausnog.net> 
>Sent: Friday, 9 August 2013 3:33 PM
>Subject: Re: [AusNOG] Application Firewall Recommendations
> 
>
>
>We've seen the same thing.  That said, I haven't worked with a firewall product which DID allow this, since it's the GRE component which would need to be inspected..  We've gotten around this by NATTING each client internally onto their own public IP address for outbound TCP port 1723, and outbound GRE.
>
>We're also have a lot of issues with gateway groups, NOT failing
      over for existing stateful sessions, when the default gateway goes
      down.  We have a symetrical link plus a bunch of ADSL links at
      each of our offices, and the config should be that if one ADSL
      link goes down, we don't care, we just start sending traffic out
      the next.  Except that does not happen if someone has already
      accessed a specific website via the ADSL link which went down -
      they can no longer access that website, unless we do a full state
      reset on the firewall. 
>
>I thought it was just one 'bad' pfsense install, but we have three
      sites showing the same issue.
>
>--DG
>
>
>On 9/08/2013 2:54 PM, Tony wrote:
>
>
>>
>>The only issues we've had with pfsense are to do with PPTP. The main issue being that it isn't capable of inspecting outbound PPTP sessions and maintaining a table similar to an outbound NAT table (am I making sense). The problem that occurs is that you can only have ONE PPTP session up between any client on the inside and any server on the outside. So if you have users on the inside of a pfsense box and two of them try to fire up a PPTP session to the SAME remote endpoint, it won't work as it can't identify the two sessions in any way as they have the same source (outside public IP of the firewall) and same remote destination and same protocol (GRE). Even inbound PPTP isn't the easiest either if you want to have outbound at the same time, you need to NAT outbound to a different public IP so it doesn't mess with inbound (which is fine if you have multiple public IP, but a bit harder if you only have a single IP).
>>
>>
>>
>>Who still uses PPTP you might say ? It's insecure, get rid of it I hear ? The problem is the remote side of things which you don't control and user in dept X absolutely have to connect to vendor Y via PPTP session to do something "really important".
>>
>>
>>
>>Other than PPTP issues, we have no problems with it and have many pfsense firewalls deployed around the place.
>>
>>
>>
>>
>>
>>regards,
>>Tony.
>>
>>
>>
>>
>>
>>
>>
>>
>>>________________________________
>>> From: Joshua D'Alton <joshua at railgun.com.au>
>>>To: Alex Samad - Yieldbroker <Alex.Samad at yieldbroker.com> 
>>>Cc: "ausnog at lists.ausnog.net" <ausnog at lists.ausnog.net> 
>>>Sent: Friday, 9 August 2013 1:26 PM
>>>Subject: Re: [AusNOG] Application Firewall Recommendations
>>> 
>>>
>>>
>>>pfsense is pretty hard to beat as a fairly full-featured firewall, I've used it in a lot of situations that don't warrant the cost of a cisco or similar setup. Works brilliantly in a VM as well.
>>>
>>>
>>>
>>
>>
>>_______________________________________________
AusNOG mailing list AusNOG at lists.ausnog.net http://lists.ausnog.net/mailman/listinfo/ausnog 
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ausnog.net/pipermail/ausnog/attachments/20130808/ae5b6e37/attachment.html>