> 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)
