On Fri, 18 Oct 2002, Me, Myself, and I blathered:
> You cannot NAT an IPSEC packet. NAT rewrites the IP headers and the
> packet will get rejected when it reaches the other IPSEC node.
I still stand by my original statement. However, it won't be true for
much longer. There is now a draft docume
As I think about it, it isn't IPSEC that needs to process twice once
before and once after ipfw. Its the other way around.
IPFW should first allow the ESP packets into the machine, then IPSEC
extracted the secured packet, and then IPFW will process the normal
packet again, thus allowing the dive
On Fri, Oct 18, 2002 at 06:39:51AM -0700, Matthew Zahorik wrote:
> On Fri, 18 Oct 2002, Andrew P. Lentvorski wrote:
>
> > You cannot NAT an IPSEC packet. NAT rewrites the IP headers and the
> > packet will get rejected when it reaches the other IPSEC node.
>
> Not exactly true. I use a Windows
Matthew Zahorik wrote:
On Fri, 18 Oct 2002, Andrew P. Lentvorski wrote:
You cannot NAT an IPSEC packet. NAT rewrites the IP headers and the
packet will get rejected when it reaches the other IPSEC node.
Not exactly true. I use a Windows Nortel Contivity client behind NAT just
fine.
Reading
Hello Matthew,
Friday, October 18, 2002, 9:39:51 PM, you wrote:
MZ> On Fri, 18 Oct 2002, Andrew P. Lentvorski wrote:
>> You cannot NAT an IPSEC packet. NAT rewrites the IP headers and the
>> packet will get rejected when it reaches the other IPSEC node.
MZ> Not exactly true. I use a Windows N
On Fri, 18 Oct 2002, Andrew P. Lentvorski wrote:
> You cannot NAT an IPSEC packet. NAT rewrites the IP headers and the
> packet will get rejected when it reaches the other IPSEC node.
Not exactly true. I use a Windows Nortel Contivity client behind NAT just
fine.
If you're using an AH associat
On a side note:
For whoever tackles this project - a sysctl variable would be nice to
turn the second ipsec processing(pre ipfw/ipf) on or off.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
You cannot NAT an IPSEC packet. NAT rewrites the IP headers and the
packet will get rejected when it reaches the other IPSEC node.
You can create forwarding rules which NAT packets destined for other hosts
and leave the IPSEC packets alone. You'll have to create an ipfw ruleset.
You also probab
Charles Henrich wrote:
The nat daemon does not log any rejections of the packet, however in my kernel
log, I see a
Oct 17 17:23:51 dmz /kernel: Connection attempt to TCP B:3283 from C:22
Your packets don't seem to reach natd after IPsec inbound processing.
Looks like ipfw processing happens be
> > I have a network/firewall where I want to nat an entire network. However,
> > I also want nat traffic to one remote host in particular out on the
> > internet to be IPsec'd as well.
> >
> > [A] (10.x) [B] (Nat) [C] (Real IP)
>
> There was a thread on -hackers named "VPN Routing through gif (
Charles Henrich wrote:
I have a network/firewall where I want to nat an entire network. However, I
also want nat traffic to one remote host in particular out on the internet to
be IPsec'd as well.
[A] (10.x) [B] (Nat) [C] (Real IP)
There was a thread on -hackers named "VPN Routing through gif
I apologize for not CC'ing originally!
I have a network/firewall where I want to nat an entire network. However, I
also want nat traffic to one remote host in particular out on the internet to
be IPsec'd as well.
[A] (10.x) [B] (Nat) [C] (Real IP)
I've setup IPsec on both machines, and from eit
12 matches
Mail list logo
