On 7/31/07, Matthew Grooms [EMAIL PROTECTED] wrote:
nat on $ext proto udp from $prv_net port 500 to any - ( $ext ) port 500
nat on $ext proto udp from $prv_net port 4500 to any - ( $ext ) port 4500
... which acts like a VPN pass-through by forcing the source port to not
be translated. This is
Bill Marquette wrote:
It's worth noting that pfSense does this by default. Some IPSec
concentrators also expect the udp traffic to source from port 500 and
won't allow connections from arbitrary ports (Nortel Contivity is such
a beast). And yes, it means we can only handle one ipsec
Bill Marquette wrote:
It's worth noting that pfSense does this by default. Some IPSec
concentrators also expect the udp traffic to source from port 500 and
won't allow connections from arbitrary ports (Nortel Contivity is such
a beast). And yes, it means we can only handle one ipsec
Matthew Grooms wrote:
Thanks for the information. I'm not a pfsense developer but I would
have to disagree with your last statement. In my opinion, making
exceptions in the default rules to work around antiquated VPN clients
is the wrong way to go.
The default configuration for all things
On 8/1/07, Matthew Grooms [EMAIL PROTECTED] wrote:
Bill,
Thanks for the information. I'm not a pfsense developer but I would have
to disagree with your last statement. In my opinion, making exceptions
in the default rules to work around antiquated VPN clients is the wrong
way to go. Maybe
On 8/1/07, Paul M [EMAIL PROTECTED] wrote:
Bill Marquette wrote:
It's worth noting that pfSense does this by default. Some IPSec
concentrators also expect the udp traffic to source from port 500 and
won't allow connections from arbitrary ports (Nortel Contivity is such
a beast). And
I am having a weird issue accessing fedex.com and I'm wondering if you can
help me determine if it is firewall related (or what it is).
Now almost all of our machines (except servers) are nat'ed to the same
external IP. (servers are 1:1 to their own public IP)
Half of our workstations can
Bill Marquette wrote:
Or corporations that refuse to enable NAT-T on their IPSec concentrators.
Which should be the exception to the rule. But as I stated before, thats
just my opinion based on my own experience supporting these platforms.
There are some limitations we have. pf/FreeBSD
On 8/1/07, Tim Dickson [EMAIL PROTECTED] wrote:
I am having a weird issue accessing fedex.com and I'm wondering if you can
help me determine if it is firewall related (or what it is).
Now almost all of our machines (except servers) are nat'ed to the same
external IP. (servers are 1:1
Plain Text noted(thanks, just wanted to get the pass image in the rule
:) )
Recommened MTU is 1504, so 1500 should be fine ( I switched to 1400 just for
kicks to no avail)
FYI, this is ONLY for fedex.com too... Am I right to assume it isn't the
firewall?
-Tim
-Original Message-
On 8/1/07, Tim Dickson [EMAIL PROTECTED] wrote:
Plain Text noted(thanks, just wanted to get the pass image in the rule
:) )
Recommened MTU is 1504, so 1500 should be fine ( I switched to 1400 just for
kicks to no avail)
FYI, this is ONLY for fedex.com too... Am I right to assume it
Am 01.08.2007 um 20:53 schrieb Scott Ullrich:
On 8/1/07, Tim Dickson [EMAIL PROTECTED] wrote:
Plain Text noted(thanks, just wanted to get the pass image in
the rule
:) )
Recommened MTU is 1504, so 1500 should be fine ( I switched to
1400 just for
kicks to no avail)
FYI, this is
I am on 1.01 release, I was holding off till final releases since this is in
production.
I can upgrade later today and try.
Occasionally it will work from a machine that doesn't work. If it ends up
working it will continue to work pretty consistently until it doesn't work
then it won't work for
Matthew Grooms wrote:
Bill Marquette wrote:
Or corporations that refuse to enable NAT-T on their IPSec
concentrators.
Which should be the exception to the rule. But as I stated before,
thats just my opinion based on my own experience supporting these
platforms.
There are some
14 matches
Mail list logo
