Jason Dixon wrote:
On Jan 4, 2006, at 9:32 AM, Hekan Olsson wrote:
On 4 jan 2006, at 05.57, Jason Dixon wrote:
After some gentle persuading by Adrian Close, I dropped ipsecadm and
went back to automatic key exchange with isakmpd. A quick
configuration based on the east/west and all is goo
On Jan 4, 2006, at 9:32 AM, Hekan Olsson wrote:
On 4 jan 2006, at 05.57, Jason Dixon wrote:
After some gentle persuading by Adrian Close, I dropped ipsecadm
and went back to automatic key exchange with isakmpd. A quick
configuration based on the east/west and all is good. Same PF
config
On 4 jan 2006, at 05.57, Jason Dixon wrote:
After some gentle persuading by Adrian Close, I dropped ipsecadm
and went back to automatic key exchange with isakmpd. A quick
configuration based on the east/west and all is good. Same PF
configuration, no changes there except for the addition
After some gentle persuading by Adrian Close, I dropped ipsecadm and
went back to automatic key exchange with isakmpd. A quick
configuration based on the east/west and all is good. Same PF
configuration, no changes there except for the addition of ISAKMP
traffic. Don't know what the prob
On Jan 3, 2006, at 9:34 PM, Joel Knight wrote:
--- Quoting Jason Dixon on 2006/01/03 at 21:11 -0500:
The original post says that "packets aren't making it to enc0 and
beyond on the remote side". Yes, I admit that I was a bit
contradictory in the next sentence that says "it's making it all the
--- Quoting Jason Dixon on 2006/01/03 at 21:11 -0500:
> The original post says that "packets aren't making it to enc0 and
> beyond on the remote side". Yes, I admit that I was a bit
> contradictory in the next sentence that says "it's making it all the
> way up to remote enc0", but I was tr
On Jan 3, 2006, at 8:51 PM, Joel Knight wrote:
--- Quoting Jason Dixon on 2006/01/03 at 19:39 -0500:
Yes, although that's more of a "part B" problem when we're still
discussing "part A". The packets aren't even making it as far as
enc0, so there certainly won't be anything to return yet.
In
--- Quoting Jason Dixon on 2006/01/03 at 19:39 -0500:
> Yes, although that's more of a "part B" problem when we're still
> discussing "part A". The packets aren't even making it as far as
> enc0, so there certainly won't be anything to return yet.
In your original email you say that "[packet
On Jan 3, 2006, at 7:32 PM, Adrian Close wrote:
On Tue, 3 Jan 2006, Joel Knight wrote:
Check the usual suspects?
net.inet.ip.forwarding=1?
Appropriate "pass" rules on the internal interface?
Verify the return path doesn't have a problem?
Also, make sure you're not blocking the ipencap packet
On Jan 3, 2006, at 7:14 PM, Joel Knight wrote:
--- Quoting Jason Dixon on 2006/01/03 at 17:08 -0500:
I'm testing a new VPN tunnel using ipsecadm and manual keying.
Everything looks ok, but packets aren't making it to enc0 and beyond
on the remote side (either way). I can watch the packet coun
On Tue, 3 Jan 2006, Joel Knight wrote:
Check the usual suspects?
net.inet.ip.forwarding=1?
Appropriate "pass" rules on the internal interface?
Verify the return path doesn't have a problem?
Also, make sure you're not blocking the ipencap packets.
Check various places with tcpdump - see what's
--- Quoting Jason Dixon on 2006/01/03 at 17:08 -0500:
> I'm testing a new VPN tunnel using ipsecadm and manual keying.
> Everything looks ok, but packets aren't making it to enc0 and beyond
> on the remote side (either way). I can watch the packet count
> increment on the relevant pass rul
I'm testing a new VPN tunnel using ipsecadm and manual keying.
Everything looks ok, but packets aren't making it to enc0 and beyond
on the remote side (either way). I can watch the packet count
increment on the relevant pass rules (see below), so I know it's
making it all the way up to re
13 matches
Mail list logo
