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)
