Toby,
Actually, I was initially using my local subnet address rather than
"any", but I realized that if did so, this address could be seen on
the remote vpn server by looking at the flows table.
After setting the "from any" rule, I realized that, yes it was more or
less working as expected, but it was screwing the internal carp
configuration on the remote side when you use the remote local subnet
as a target rather than 172.25.0.1. So I think it's not a good idea
anyway.
So I decided to try to set it up your way, with a manual flow directive.
I could make it work using something like :
ike esp from A.B.C.D to 172.25.0.1. peer W.X.Y.Z
flow from <my.local.subnet> to 172.25.0.1 peer W.X.Y.Z type require
(note that I had to set "require" to make it work)
But again the local subnet appears if you look at the flows on the
remote servers, so that's not what you want.
If I use "any" in place of my local subnet address, it doesn't work
for some reason I don't understand yet, I am just losing track of my
packets...
So I guess that as you said, you should try to get more informations
about the remote side configuration.
I would still be interested in knowing the clean and mighty way to
hide your local subnet topography.
Maybe using an intermediate local interface may help, as it was
suggested by Marc-Andre.
Regards,
William
2008/8/15 Toby Burress <[EMAIL PROTECTED]>:
> On Fri, Aug 15, 2008 at 05:09:08PM +0900, william dunand wrote:
>> Of course, as it is a testing environment it is a lot easier to make
>> it work for me...
>> On the remote side, a configured something like this (I suppose they
>> have something of this kind on the other side) :
>> ike passive esp from 172.25.0.1 to A.B.C.D
>>
>> And on the local server side, all I have is :
>> ike esp from any to 172.25.0.1 peer W.X.Y.Z
>
> Ah, okay. It doesn't look like I have the luxury of simply saying
> 'from any to IP', since the remote end refuses to set up the SAs
> in that case. I will try to get the other end to allow something
> like that, since it seems like a MUCH better solution than the rube
> goldberg stuff I'm playing with now, but half the reason I'm stuck
> is the other guy doesn't return emails...
>
>>
>> Never tried to use the "flow" directives as you did. I suppose that if
>> as you said you have correct encap routes, packets headed to
>> 172.25.0.1 should definitely go through enc0, then if you set nat on
>> enc0, it should work as it does for me.
>> Could you paste and show us the output of netstat -rnf encap and also
>> if possible your pf.conf ?
>
> Encap:
> Source Port Destination Port Proto
> SA(Address/Proto/Type/Direction)
> 172.25.0.1/32 0 A.B.C.D/32 0 0 W.X.Y.Z/esp/use/in
> A.B.C.D/32 0 172.25.0.1/32 0 0
> W.X.Y.Z/esp/require/out
> 172.25.0.1/32 0 default 0 0 W.X.Y.Z/esp/use/in
> default 0 172.25.0.1/32 0 0 W.X.Y.Z/esp/use/out
>
>
> The pf.conf is pretty complicated, but the relevant rules that get hit are:
>
> ext_if="bge1"
> int_if="bge0"
> vpn_if="enc0"
> set ruleset-optimization none
> set state-policy if-bound
> set skip on { lo }
> scrub all fragment reassemble reassemble tcp
> nat on $vpn_if from 192.168.0.0/16 to any -> A.B.C.D
> nat on $ext_if from 192.168.0.0/16 to any -> E.F.G.H
> block drop
> pass quick on $vpn_if
> pass quick on $int_if
>
> And then there are others that eventually let us out of $ext_if as well.
