pf & isakmpd: NAT through encryption interface?

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

pf & isakmpd: NAT through encryption interface?

posting (Bugzilla)
Imagine the following scenario:

You have two VPN endpoints. One is an OpenBSD system running isakmpd and
pf, the other is a VPN concentrator from some vendor.

The OpenBSD already has other VPNs set up, all using the same internal
network. Renumbering isn't going to work.

The VPN concentrator operator has an internal addressing scheme he
insists other endpoints conform to.

The question, then:

Is it even possible to NAT through an encryption interface? For example:

OpenBSD internal network: 192.168.45.0/24
Network other guy would prefer OpenBSD use: 10.110.40.0/24

Network other guy is using: 10.110.10.0/24

The command might look like this:

nat on $enc_if from 192.168.45.0:network to 10.110.10.0:network ->
10.110.40.10

Forgive me if this i) is impossible, ii) is crazy, iii) the syntax of
the command is wrong.

I'd rather run it past the list than tinker on production equipment.

Thanks for any help and advice,

-Stephen-

Reply | Threaded
Open this post in threaded view
|

Re: pf & isakmpd: NAT through encryption interface?

Dag Richards
Stephen Bosch wrote:

> Imagine the following scenario:
>
> You have two VPN endpoints. One is an OpenBSD system running isakmpd and
> pf, the other is a VPN concentrator from some vendor.
>
> The OpenBSD already has other VPNs set up, all using the same internal
> network. Renumbering isn't going to work.
>
> The VPN concentrator operator has an internal addressing scheme he
> insists other endpoints conform to.
>
> The question, then:
>
> Is it even possible to NAT through an encryption interface? For example:
>
> OpenBSD internal network: 192.168.45.0/24
> Network other guy would prefer OpenBSD use: 10.110.40.0/24
>
> Network other guy is using: 10.110.10.0/24
>
> The command might look like this:
>
> nat on $enc_if from 192.168.45.0:network to 10.110.10.0:network ->
> 10.110.40.10
>
> Forgive me if this i) is impossible, ii) is crazy, iii) the syntax of
> the command is wrong.
>
> I'd rather run it past the list than tinker on production equipment.
>
> Thanks for any help and advice,
>
> -Stephen-
>
blind leading the blind here but ....
This was recently discussed, and it was pointed out that
the decision to encrypt happens before the nat-ing.

I deal with this self same issue by the lazy expedient of a firewall
with a vpn server that has one interface in the dmz and one on the
public net.  So I do the vendor mandated nat-ing and pass to the vpn
server.  This made writing the pf rules for both sets of machines pretty
straight forward.

Reply | Threaded
Open this post in threaded view
|

Re: pf & isakmpd: NAT through encryption interface?

posting (Bugzilla)
Dag Richards wrote:

> Stephen Bosch wrote:
>> Imagine the following scenario:
>>
>> You have two VPN endpoints. One is an OpenBSD system running isakmpd
>> and pf, the other is a VPN concentrator from some vendor.
>>
>> The OpenBSD already has other VPNs set up, all using the same internal
>> network. Renumbering isn't going to work.
>>
>> The VPN concentrator operator has an internal addressing scheme he
>> insists other endpoints conform to.
>>
>> The question, then:
>>
>> Is it even possible to NAT through an encryption interface? For example:
>>
>> OpenBSD internal network: 192.168.45.0/24
>> Network other guy would prefer OpenBSD use: 10.110.40.0/24
>>
>> Network other guy is using: 10.110.10.0/24
>>
>> The command might look like this:
>>
>> nat on $enc_if from 192.168.45.0:network to 10.110.10.0:network ->
>> 10.110.40.10
>>
>> Forgive me if this i) is impossible, ii) is crazy, iii) the syntax of
>> the command is wrong.
>>
>> I'd rather run it past the list than tinker on production equipment.
>>
>> Thanks for any help and advice,
>>
>> -Stephen-
>>
> blind leading the blind here but ....
> This was recently discussed, and it was pointed out that
> the decision to encrypt happens before the nat-ing.

Correct me if I am wrong, then -- this should work. I should be able to
set up a NAT rule that will affect encrypted traffic in the way I want.

Someone mentioned to me that this does work in 3.9. Will it work in 3.8?
That's what our gear is running.

-Stephen-

Reply | Threaded
Open this post in threaded view
|

Re: pf & isakmpd: NAT through encryption interface?

Dag Richards
Stephen Bosch wrote:

> Dag Richards wrote:
>> Stephen Bosch wrote:
>>> Imagine the following scenario:
>>>
>>> You have two VPN endpoints. One is an OpenBSD system running isakmpd
>>> and pf, the other is a VPN concentrator from some vendor.
>>>
>>> The OpenBSD already has other VPNs set up, all using the same
>>> internal network. Renumbering isn't going to work.
>>>
>>> The VPN concentrator operator has an internal addressing scheme he
>>> insists other endpoints conform to.
>>>
>>> The question, then:
>>>
>>> Is it even possible to NAT through an encryption interface? For example:
>>>
>>> OpenBSD internal network: 192.168.45.0/24
>>> Network other guy would prefer OpenBSD use: 10.110.40.0/24
>>>
>>> Network other guy is using: 10.110.10.0/24
>>>
>>> The command might look like this:
>>>
>>> nat on $enc_if from 192.168.45.0:network to 10.110.10.0:network ->
>>> 10.110.40.10
>>>
>>> Forgive me if this i) is impossible, ii) is crazy, iii) the syntax of
>>> the command is wrong.
>>>
>>> I'd rather run it past the list than tinker on production equipment.
>>>
>>> Thanks for any help and advice,
>>>
>>> -Stephen-
>>>
>> blind leading the blind here but ....
>> This was recently discussed, and it was pointed out that
>> the decision to encrypt happens before the nat-ing.
>
> Correct me if I am wrong, then -- this should work. I should be able to
> set up a NAT rule that will affect encrypted traffic in the way I want.
>
> Someone mentioned to me that this does work in 3.9. Will it work in 3.8?
> That's what our gear is running.
>
> -Stephen-
>
Um no, it wont work. Once the traffic is encrypted you will no longer be
able to nat it.  The original packet is now and encrypted blob that is
the payload of a new packet with a source of your gateway and dest their
GW. you can nat the wrapper packet but not the payload.

I have 2x ibm x series somethings for fw's, and 2x hp dl360s for vpn
servers all running 3.9.

Reply | Threaded
Open this post in threaded view
|

Re: pf & isakmpd: NAT through encryption interface?

Morris, Roy
In reply to this post by posting (Bugzilla)
> Stephen Bosch wrote:
> > Dag Richards wrote:
> >> Stephen Bosch wrote:
> >>> Imagine the following scenario:
> >>>
> >>> You have two VPN endpoints. One is an OpenBSD system
> running isakmpd
> >>> and pf, the other is a VPN concentrator from some vendor.
> >>>
> >>> The OpenBSD already has other VPNs set up, all using the same
> >>> internal network. Renumbering isn't going to work.
> >>>
> >>> The VPN concentrator operator has an internal addressing
> scheme he
> >>> insists other endpoints conform to.
> >>>
> >>> The question, then:
> >>>
> >>> Is it even possible to NAT through an encryption
> interface? For example:
> >>>
> >>> OpenBSD internal network: 192.168.45.0/24
> >>> Network other guy would prefer OpenBSD use: 10.110.40.0/24
> >>>
> >>> Network other guy is using: 10.110.10.0/24
> >>>
> >>> The command might look like this:
> >>>
> >>> nat on $enc_if from 192.168.45.0:network to
> 10.110.10.0:network ->
> >>> 10.110.40.10
> >>>
> >>> Forgive me if this i) is impossible, ii) is crazy, iii)
> the syntax of
> >>> the command is wrong.
> >>>
> >>> I'd rather run it past the list than tinker on production
> equipment.
> >>>
> >>> Thanks for any help and advice,
> >>>
> >>> -Stephen-
> >>>
> >> blind leading the blind here but ....
> >> This was recently discussed, and it was pointed out that
> >> the decision to encrypt happens before the nat-ing.
> >
> > Correct me if I am wrong, then -- this should work. I
> should be able to
> > set up a NAT rule that will affect encrypted traffic in the
> way I want.
> >
> > Someone mentioned to me that this does work in 3.9. Will it
> work in 3.8?
> > That's what our gear is running.
> >
> > -Stephen-
> >
> Um no, it wont work. Once the traffic is encrypted you will
> no longer be
> able to nat it.  The original packet is now and encrypted
> blob that is
> the payload of a new packet with a source of your gateway and
> dest their
> GW. you can nat the wrapper packet but not the payload.
>
> I have 2x ibm x series somethings for fw's, and 2x hp dl360s for vpn
> servers all running 3.9.

Yes it does work! I guess I better hold on to these two boxes I have. Seems
they are the only ones that do! lol

I have
A. clients on each end behind a vpn/pf box
B. enc0 binat from internal client to public IP of other side client
C. /etc/hostname.if alias for the binat IP
D. isakmpd.conf uses public IP (A) for phase 1, and (B internal client nat) for
phase 2


(ip's changed to protect the innocent. No animals were harmed during this test)

Jun 28 13:23:32.881298 (authentic,confidential): SPI 0x84adb14b: 222.222.222.111 > 111.111.111.111: 222.222.222.222.25247 > 111.111.111.222.80: S [tcp sum ok] 789729009:789729009(0) win 16384 <mss 1460,nop,nop,sackOK,nop,wscale 0,nop,nop,timestamp 345218535 0> (DF) [tos 0x10] (ttl 63, id 29296, len 64) (DF) [tos 0x10] (ttl 63, id 44546, len 84)
Jun 28 13:23:32.882822 (authentic,confidential): SPI 0xcf4b18fb: 111.111.111.111 > 222.222.222.111: 111.111.111.222.80 > 222.222.222.222.25247: S [tcp sum ok] 3946347346:3946347346(0) ack 789729010 win 16384 <mss 1460,nop,nop,sackOK,nop,wscale 0,nop,nop,timestamp 1861954054 345218535> (DF) (ttl 63, id 35574, len 64) (DF) (ttl 64, id 12842, len 84, bad cksum 0!)
Jun 28 13:23:32.883716 (authentic,confidential): SPI 0x84adb14b: 222.222.222.111 > 111.111.111.111: 222.222.222.222.25247 > 111.111.111.222.80: . [tcp sum ok] ack 1 win 17376 <nop,nop,timestamp 345218535 1861954054> (DF) [tos 0x10] (ttl 63, id 31269, len 52) (DF) [tos 0x10] (ttl 63, id 34993, len 72)
Jun 28 13:23:37.013444 (authentic,confidential): SPI 0x84adb14b: 222.222.222.111 > 111.111.111.111: 222.222.222.222.25247 > 111.111.111.222.80: F [tcp sum ok] 1:1(0) ack 1 win 17376 <nop,nop,timestamp 345218543 1861954054> (DF) [tos 0x10] (ttl 63, id 30180, len 52) (DF) [tos 0x10] (ttl 63, id 61997, len 72)
Jun 28 13:23:37.013716 (authentic,confidential): SPI 0xcf4b18fb: 111.111.111.111 > 222.222.222.111: 111.111.111.222.80 > 222.222.222.222.25247: . [tcp sum ok] ack 2 win 17376 <nop,nop,timestamp 1861954062 345218543> (DF) (ttl 63, id 56710, len 52) (DF) (ttl 64, id 21978, len 72, bad cksum 0!)
Jun 28 13:23:37.013806 (authentic,confidential): SPI 0xcf4b18fb: 111.111.111.111 > 222.222.222.111: 111.111.111.222.80 > 222.222.222.222.25247: F [tcp sum ok] 1:1(0) ack 2 win 17376 <nop,nop,timestamp 1861954062 345218543> (DF) (ttl 63, id 40038, len 52) (DF) (ttl 64, id 19310, len 72, bad cksum 0!)
Jun 28 13:23:37.014441 (authentic,confidential): SPI 0x84adb14b: 222.222.222.111 > 111.111.111.111: 222.222.222.222.25247 > 111.111.111.222.80: . [tcp sum ok] ack 2 win 17375 <nop,nop,timestamp 345218543 1861954062> (DF) [tos 0x10] (ttl 63, id 838, len 52) (DF) [tos 0x10] (ttl 63, id 53227, len 72)
Jun 28 13:23:38.749637 (authentic,confidential): SPI 0x84adb14b: 222.222.222.111 > 111.111.111.111: 222.222.222.222.40612 > 111.111.111.222.80: S [tcp sum ok] 402874189:402874189(0) win 16384 <mss 1460,nop,nop,sackOK,nop,wscale 0,nop,nop,timestamp 345218547 0> (DF) [tos 0x10] (ttl 63, id 9220, len 64) (DF) [tos 0x10] (ttl 63, id 51268, len 84)
Jun 28 13:23:38.749953 (authentic,confidential): SPI 0xcf4b18fb: 111.111.111.111 > 222.222.222.111: 111.111.111.222.80 > 222.222.222.222.40612: S [tcp sum ok] 2637765617:2637765617(0) ack 402874190 win 16384 <mss 1460,nop,nop,sackOK,nop,wscale 0,nop,nop,timestamp 1723892848 345218547> (DF) (ttl 63, id 64094, len 64) (DF) (ttl 64, id 31080, len 84, bad cksum 0!)
Jun 28 13:23:38.750648 (authentic,confidential): SPI 0x84adb14b: 222.222.222.111 > 111.111.111.111: 222.222.222.222.40612 > 111.111.111.222.80: . [tcp sum ok] ack 1 win 17376 <nop,nop,timestamp 345218547 1723892848> (DF) [tos 0x10] (ttl 63, id 6907, len 52) (DF) [tos 0x10] (ttl 63, id 62250, len 72)

Reply | Threaded
Open this post in threaded view
|

Re: pf & isakmpd: NAT through encryption interface?

Dag Richards
Roy Morris wrote:

>> Stephen Bosch wrote:
>>> Dag Richards wrote:
>>>> Stephen Bosch wrote:
>>>>> Imagine the following scenario:
>>>>>
>>>>> You have two VPN endpoints. One is an OpenBSD system
>> running isakmpd
>>>>> and pf, the other is a VPN concentrator from some vendor.
>>>>>
>>>>> The OpenBSD already has other VPNs set up, all using the same
>>>>> internal network. Renumbering isn't going to work.
>>>>>
>>>>> The VPN concentrator operator has an internal addressing
>> scheme he
>>>>> insists other endpoints conform to.
>>>>>
>>>>> The question, then:
>>>>>
>>>>> Is it even possible to NAT through an encryption
>> interface? For example:
>>>>> OpenBSD internal network: 192.168.45.0/24
>>>>> Network other guy would prefer OpenBSD use: 10.110.40.0/24
>>>>>
>>>>> Network other guy is using: 10.110.10.0/24
>>>>>
>>>>> The command might look like this:
>>>>>
>>>>> nat on $enc_if from 192.168.45.0:network to
>> 10.110.10.0:network ->
>>>>> 10.110.40.10
>>>>>
>>>>> Forgive me if this i) is impossible, ii) is crazy, iii)
>> the syntax of
>>>>> the command is wrong.
>>>>>
>>>>> I'd rather run it past the list than tinker on production
>> equipment.
>>>>> Thanks for any help and advice,
>>>>>
>>>>> -Stephen-
>>>>>
>>>> blind leading the blind here but ....
>>>> This was recently discussed, and it was pointed out that
>>>> the decision to encrypt happens before the nat-ing.
>>> Correct me if I am wrong, then -- this should work. I
>> should be able to
>>> set up a NAT rule that will affect encrypted traffic in the
>> way I want.
>>> Someone mentioned to me that this does work in 3.9. Will it
>> work in 3.8?
>>> That's what our gear is running.
>>>
>>> -Stephen-
>>>
>> Um no, it wont work. Once the traffic is encrypted you will
>> no longer be
>> able to nat it.  The original packet is now and encrypted
>> blob that is
>> the payload of a new packet with a source of your gateway and
>> dest their
>> GW. you can nat the wrapper packet but not the payload.
>>
>> I have 2x ibm x series somethings for fw's, and 2x hp dl360s for vpn
>> servers all running 3.9.
>
> Yes it does work! I guess I better hold on to these two boxes I have. Seems
> they are the only ones that do! lol
>
> I have
> A. clients on each end behind a vpn/pf box
> B. enc0 binat from internal client to public IP of other side client
> C. /etc/hostname.if alias for the binat IP
> D. isakmpd.conf uses public IP (A) for phase 1, and (B internal client nat) for
> phase 2
>
>
> (ip's changed to protect the innocent. No animals were harmed during this test)
>
> Jun 28 13:23:32.881298 (authentic,confidential): SPI 0x84adb14b: 222.222.222.111 > 111.111.111.111: 222.222.222.222.25247 > 111.111.111.222.80: S [tcp sum ok] 789729009:789729009(0) win 16384 <mss 1460,nop,nop,sackOK,nop,wscale 0,nop,nop,timestamp 345218535 0> (DF) [tos 0x10] (ttl 63, id 29296, len 64) (DF) [tos 0x10] (ttl 63, id 44546, len 84)
> Jun 28 13:23:32.882822 (authentic,confidential): SPI 0xcf4b18fb: 111.111.111.111 > 222.222.222.111: 111.111.111.222.80 > 222.222.222.222.25247: S [tcp sum ok] 3946347346:3946347346(0) ack 789729010 win 16384 <mss 1460,nop,nop,sackOK,nop,wscale 0,nop,nop,timestamp 1861954054 345218535> (DF) (ttl 63, id 35574, len 64) (DF) (ttl 64, id 12842, len 84, bad cksum 0!)
> Jun 28 13:23:32.883716 (authentic,confidential): SPI 0x84adb14b: 222.222.222.111 > 111.111.111.111: 222.222.222.222.25247 > 111.111.111.222.80: . [tcp sum ok] ack 1 win 17376 <nop,nop,timestamp 345218535 1861954054> (DF) [tos 0x10] (ttl 63, id 31269, len 52) (DF) [tos 0x10] (ttl 63, id 34993, len 72)
> Jun 28 13:23:37.013444 (authentic,confidential): SPI 0x84adb14b: 222.222.222.111 > 111.111.111.111: 222.222.222.222.25247 > 111.111.111.222.80: F [tcp sum ok] 1:1(0) ack 1 win 17376 <nop,nop,timestamp 345218543 1861954054> (DF) [tos 0x10] (ttl 63, id 30180, len 52) (DF) [tos 0x10] (ttl 63, id 61997, len 72)
> Jun 28 13:23:37.013716 (authentic,confidential): SPI 0xcf4b18fb: 111.111.111.111 > 222.222.222.111: 111.111.111.222.80 > 222.222.222.222.25247: . [tcp sum ok] ack 2 win 17376 <nop,nop,timestamp 1861954062 345218543> (DF) (ttl 63, id 56710, len 52) (DF) (ttl 64, id 21978, len 72, bad cksum 0!)
> Jun 28 13:23:37.013806 (authentic,confidential): SPI 0xcf4b18fb: 111.111.111.111 > 222.222.222.111: 111.111.111.222.80 > 222.222.222.222.25247: F [tcp sum ok] 1:1(0) ack 2 win 17376 <nop,nop,timestamp 1861954062 345218543> (DF) (ttl 63, id 40038, len 52) (DF) (ttl 64, id 19310, len 72, bad cksum 0!)
> Jun 28 13:23:37.014441 (authentic,confidential): SPI 0x84adb14b: 222.222.222.111 > 111.111.111.111: 222.222.222.222.25247 > 111.111.111.222.80: . [tcp sum ok] ack 2 win 17375 <nop,nop,timestamp 345218543 1861954062> (DF) [tos 0x10] (ttl 63, id 838, len 52) (DF) [tos 0x10] (ttl 63, id 53227, len 72)
> Jun 28 13:23:38.749637 (authentic,confidential): SPI 0x84adb14b: 222.222.222.111 > 111.111.111.111: 222.222.222.222.40612 > 111.111.111.222.80: S [tcp sum ok] 402874189:402874189(0) win 16384 <mss 1460,nop,nop,sackOK,nop,wscale 0,nop,nop,timestamp 345218547 0> (DF) [tos 0x10] (ttl 63, id 9220, len 64) (DF) [tos 0x10] (ttl 63, id 51268, len 84)
> Jun 28 13:23:38.749953 (authentic,confidential): SPI 0xcf4b18fb: 111.111.111.111 > 222.222.222.111: 111.111.111.222.80 > 222.222.222.222.40612: S [tcp sum ok] 2637765617:2637765617(0) ack 402874190 win 16384 <mss 1460,nop,nop,sackOK,nop,wscale 0,nop,nop,timestamp 1723892848 345218547> (DF) (ttl 63, id 64094, len 64) (DF) (ttl 64, id 31080, len 84, bad cksum 0!)
> Jun 28 13:23:38.750648 (authentic,confidential): SPI 0x84adb14b: 222.222.222.111 > 111.111.111.111: 222.222.222.222.40612 > 111.111.111.222.80: . [tcp sum ok] ack 1 win 17376 <nop,nop,timestamp 345218547 1723892848> (DF) [tos 0x10] (ttl 63, id 6907, len 52) (DF) [tos 0x10] (ttl 63, id 62250, len 72)
>
>
OK I thought you were trying to change the internal client addr to an
arbitrary third addr ... oh that is what you did.

I'll be dipped. So  I better go back and re-read he earlier discussion
as I clearly did not understand it.

Reply | Threaded
Open this post in threaded view
|

Re: pf & isakmpd: NAT through encryption interface?

Roy Morris-4
In reply to this post by Morris, Roy
Roy Morris wrote:

>> Stephen Bosch wrote:
>>> Dag Richards wrote:
>>>> Stephen Bosch wrote:
>>>>> Imagine the following scenario:
>>>>>
>>>>> You have two VPN endpoints. One is an OpenBSD system
>> running isakmpd
>>>>> and pf, the other is a VPN concentrator from some vendor.
>>>>>
>>>>> The OpenBSD already has other VPNs set up, all using the same
>>>>> internal network. Renumbering isn't going to work.
>>>>>
>>>>> The VPN concentrator operator has an internal addressing
>> scheme he
>>>>> insists other endpoints conform to.
>>>>>
>>>>> The question, then:
>>>>>
>>>>> Is it even possible to NAT through an encryption
>> interface? For example:
>>>>> OpenBSD internal network: 192.168.45.0/24
>>>>> Network other guy would prefer OpenBSD use: 10.110.40.0/24
>>>>>
>>>>> Network other guy is using: 10.110.10.0/24
>>>>>
>>>>> The command might look like this:
>>>>>
>>>>> nat on $enc_if from 192.168.45.0:network to
>> 10.110.10.0:network ->
>>>>> 10.110.40.10
>>>>>
>>>>> Forgive me if this i) is impossible, ii) is crazy, iii)
>> the syntax of
>>>>> the command is wrong.
>>>>>
>>>>> I'd rather run it past the list than tinker on production
>> equipment.
>>>>> Thanks for any help and advice,
>>>>>
>>>>> -Stephen-
>>>>>
>>>> blind leading the blind here but ....
>>>> This was recently discussed, and it was pointed out that
>>>> the decision to encrypt happens before the nat-ing.
>>> Correct me if I am wrong, then -- this should work. I
>> should be able to
>>> set up a NAT rule that will affect encrypted traffic in the
>> way I want.
>>> Someone mentioned to me that this does work in 3.9. Will it
>> work in 3.8?
>>> That's what our gear is running.
>>>
>>> -Stephen-
>>>
>> Um no, it wont work. Once the traffic is encrypted you will
>> no longer be
>> able to nat it.  The original packet is now and encrypted
>> blob that is
>> the payload of a new packet with a source of your gateway and
>> dest their
>> GW. you can nat the wrapper packet but not the payload.
>>
>> I have 2x ibm x series somethings for fw's, and 2x hp dl360s for vpn
>> servers all running 3.9.


Just for clarity, I made this diagram, so we are all talking about the
same thing.
http://www.openalternatives.com/oa-ipsec.png

Reply | Threaded
Open this post in threaded view
|

Re: pf & isakmpd: NAT through encryption interface?

Markus Wernig
In reply to this post by Dag Richards
Dag Richards wrote:

> Um no, it wont work. Once the traffic is encrypted you will no longer be
> able to nat it.  The original packet is now and encrypted blob that is
> the payload of a new packet with a source of your gateway and dest their
> GW. you can nat the wrapper packet but not the payload.

Just a thought: how about building the tunnel for the nat-ed network
only? In this case something along the lines of:

ipsec.conf:
        flow esp from 10.110.40.0/24 to 10.110.10.0/24 peer $remote_gw
        [...]
and
pf.conf
        nat on $int_if from 192.168.45.0/24 to 10.110.10.0/24 -> 10.110.40.0/24
source-hash
        [...]

The packet would then have to be reinserted at a point before the
encryption decision is made ... I'm not sure if this is possible at all
... if there's a way to redirect the packet to the internal interface
again, as if it were just arriving, it should be, though ...

krgds /markus

Reply | Threaded
Open this post in threaded view
|

Re: pf & isakmpd: NAT through encryption interface?

posting (Bugzilla)
In reply to this post by Morris, Roy
Hi, Roy:

Roy Morris wrote:

>
> Yes it does work! I guess I better hold on to these two boxes I have. Seems
> they are the only ones that do! lol
>
> I have
> A. clients on each end behind a vpn/pf box
> B. enc0 binat from internal client to public IP of other side client
> C. /etc/hostname.if alias for the binat IP
> D. isakmpd.conf uses public IP (A) for phase 1, and (B internal client nat) for
> phase 2

I've had a closer look at this...

In my case, the other peer expects a private IP on my internal network.
Your directions involve an alias. Do I need this alias?

Can I not just nat on the encryption interface like so?

nat on $enc_if from $internal_ip to $remote_internal_ip ->
$private_nat_address?

This is really confusing me.

-Stephen-

Reply | Threaded
Open this post in threaded view
|

Re: pf & isakmpd: NAT through encryption interface?

posting (Bugzilla)
In reply to this post by Morris, Roy
Roy Morris wrote:

>> Stephen Bosch wrote:
>> Dag Richards wrote:
>> Um no, it wont work. Once the traffic is encrypted you will
>> no longer be
>> able to nat it.  The original packet is now and encrypted
>> blob that is
>> the payload of a new packet with a source of your gateway and
>> dest their
>> GW. you can nat the wrapper packet but not the payload.
>>
>> I have 2x ibm x series somethings for fw's, and 2x hp dl360s for vpn
>> servers all running 3.9.
>
> Yes it does work! I guess I better hold on to these two boxes I have. Seems
> they are the only ones that do! lol
>
> I have
> A. clients on each end behind a vpn/pf box
> B. enc0 binat from internal client to public IP of other side client
> C. /etc/hostname.if alias for the binat IP
> D. isakmpd.conf uses public IP (A) for phase 1, and (B internal client nat) for
> phase 2

Just to be clear here, I'll try and explain in greater detail.

I have a host with IP 10.225.10.10.

The remote network is 10.40.10.0/24.

The remote network insists that my internal host be on the 10.50.10.0/24
network. In a perfect world, I'd just renumber on my end, or get him to
accept my internal network, but he won't do that. So I have to NAT my
internal network to a private IP that fits his addressing scheme.

I need to NAT 10.225.10.10 so that it will appear as 10.50.10.10 in the
remote peer's tunnel.

If NAT happens before encryption, then this should be possible.

If NAT happens after encryption, I have a problem, and an alias doesn't
look like it's going to help.

Feedback?

-Stephen-

Reply | Threaded
Open this post in threaded view
|

Re: pf & isakmpd: NAT through encryption interface?

Morris, Roy
In reply to this post by posting (Bugzilla)
> Hi, Roy:
>
> Roy Morris wrote:
> >
> > Yes it does work! I guess I better hold on to these two
> boxes I have. Seems
> > they are the only ones that do! lol
> >
> > I have
> > A. clients on each end behind a vpn/pf box
> > B. enc0 binat from internal client to public IP of other side client
> > C. /etc/hostname.if alias for the binat IP
> > D. isakmpd.conf uses public IP (A) for phase 1, and (B
> internal client nat) for
> > phase 2
>
> I've had a closer look at this...
>
> In my case, the other peer expects a private IP on my
> internal network.
> Your directions involve an alias. Do I need this alias?
>
> Can I not just nat on the encryption interface like so?
>
> nat on $enc_if from $internal_ip to $remote_internal_ip ->
> $private_nat_address?
>
> This is really confusing me.
>
> -Stephen-
Have you actually tried it?
nat on enc0 from $ip_to_be_changed to $peer_net -> $nat_ip

Reply | Threaded
Open this post in threaded view
|

Re: pf & isakmpd: NAT through encryption interface?

Matthew Closson
In reply to this post by posting (Bugzilla)
On Wed, 28 Jun 2006, Stephen Bosch wrote:

> Hi, Roy:
>
> Roy Morris wrote:
>>
>> Yes it does work! I guess I better hold on to these two boxes I have. Seems
>> they are the only ones that do! lol
>> I have
>> A. clients on each end behind a vpn/pf box
>> B. enc0 binat from internal client to public IP of other side client
>> C. /etc/hostname.if alias for the binat IP
>> D. isakmpd.conf uses public IP (A) for phase 1, and (B internal client nat)
>> for phase 2
>
> I've had a closer look at this...
>
> In my case, the other peer expects a private IP on my internal network. Your
> directions involve an alias. Do I need this alias?
>
> Can I not just nat on the encryption interface like so?
>
> nat on $enc_if from $internal_ip to $remote_internal_ip ->
> $private_nat_address?
>
> This is really confusing me.
>
> -Stephen-
>
>

If you do nat on $enc_if your incoming packets will not match an existing
IPSEC flow and will never get routed to your enc0 interface in the first place.

man ipsec shows a flow diagram of how packets move in the kernel

  -Matt-