Re: Route traffic between two IPSEC tunnels
Thank you Stuart, I am aware of this feature, but that way I can only NAT from one network(the one in parenthesis) trough tunnel: ike esp from 10.10.10.1 (192.168.1.0/24) to 192.168.2.0/24 \ peer 10.10.20.1 I already have that configured for the tunnel between headquarters and a customer, Packets coming from remote office aren't in any of that networks. I found one solution, without the above. I add a static route to customers lan gw 127.0.0.1, and than I do nat on the lo0 from HQ's LAN and RemoteOffice LAN to Customers LAN, and it works well, you can do nat from any local or remote network through a tunnel. But, rdr doesn't work. Packets come, get redirected, get replied to, but then they are not passed back because they hit SAD matching first. Too bad. -Original Message- From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of Stuart Henderson Sent: Sunday, January 17, 2010 2:11 PM To: misc@openbsd.org Subject: Re: Route traffic between two IPSEC tunnels Take a look at OUTGOING NETWORK ADDRESS TRANSLATION in ipsec.conf(5). On 2010-01-16, Mihajlo Manojlov wrote: > Hello everybody, > > is there any way to route traffic between two ipsec tunnels, like in this > example: > > Lan1---|Router1|--Wan1---|INTERNET|---Wan2---|Router2|---Lan2 > | > Wan3 > | > |Router3| > | > Lan3 > > Router1 is at company's headquarters, Router2 is at remote office and Router3 > is a customer. > Headquarters's Lan1 is connected to remote office's Lan2 and customer's Lan3 > over an IPSec tunnel. > Lan1 <--IPSec--> Lan2 > Lan1 <--IPSec--> Lan3 > > I would like to allow communication between remote offfice's Lan2 to > customer's Lan3 over the Router1. > Lan2 <--IPSec - Router1 - IPSec --> Lan3 > > In Linux, I would just add one more tunnel from remote office's Wan2 to > headquarters's Wan1 with Lan2 and customers Lan3 defined as SA's. > Then I would tell iptables to nat everything from Lan2 to Lan3 --> Lan1 IP. > Request would come from Lan2 to Lan3 over second defined tunnel between > Router2 and Router1 and there it would be NAT-ed to Lan1 IP and sent forward > to Lan3 over the existing tunnel between Router1 and Router3. > > Can I do that with pf and isakmpd ? > > Thank you very much
Route traffic between two IPSEC tunnels
Hello everybody, is there any way to route traffic between two ipsec tunnels, like in this example: Lan1---|Router1|--Wan1---|INTERNET|---Wan2---|Router2|---Lan2 | Wan3 | |Router3| | Lan3 Router1 is at company's headquarters, Router2 is at remote office and Router3 is a customer. Headquarters's Lan1 is connected to remote office's Lan2 and customer's Lan3 over an IPSec tunnel. Lan1 <--IPSec--> Lan2 Lan1 <--IPSec--> Lan3 I would like to allow communication between remote offfice's Lan2 to customer's Lan3 over the Router1. Lan2 <--IPSec - Router1 - IPSec --> Lan3 In Linux, I would just add one more tunnel from remote office's Wan2 to headquarters's Wan1 with Lan2 and customers Lan3 defined as SA's. Then I would tell iptables to nat everything from Lan2 to Lan3 --> Lan1 IP. Request would come from Lan2 to Lan3 over second defined tunnel between Router2 and Router1 and there it would be NAT-ed to Lan1 IP and sent forward to Lan3 over the existing tunnel between Router1 and Router3. Can I do that with pf and isakmpd ? Thank you very much
Re: sasyncd syncs only newly created sad's
Thank you very much for you reply Markus, I think I saw that page once on the beginning of my research, but I tought that it must have been fixed by today, since it is almost 5 years old. I am very suprised by the fact that it hasn't been fixed in all this years. You are right, this would really be a killer app. I tought it was, since there is no way to know about this bug until you implement the whole redundant system. This problem should be clearly stated in the man page, it would save me a week. It looks like some trivial bug, since it is clear from the logs that master sends the sad's, but slave is not able to install them: sasyncd[26685]: pfkey_queue_message: pfkey ADD len 504 seq 2 sasyncd[26685]: pfkey: msg ADD write() failed on socket 5: Invalid argument but later when renegotiation occurs, it installs them succesfully: sasyncd[26685]: pfkey_queue_message: pfkey ADD len 416 seq 149 sasyncd[26685]: pfkey_queue_message: pfkey ADD len 416 seq 150 I wonder what could be different in the first try? Do you still use sasyncd? Have you found any workaround for this? I have advskew 10 on master and 20 on slave. If I want to reboot the master, I demote its carp group and while it reboots, I do: for i in `ls /etc/ | grep carp | cut -d . -f 2`; do ifconfig $i advskew 1; done on the slave. That way, master doesnt take over when it comes back. Maybe it could be done with turning off the preemtion, but haven't tried that yet. Anyhow, after that, I have to wait for all tunnels to renegotiate so I can demote the slave and make the master - master, again. Since you reported problem 5 years ago, are we the only ones who use sasyncd? :) Thanks again -Original Message- From: Markus Wernig [mailto:liste...@wernig.net] Sent: Tuesday, January 12, 2010 9:24 PM To: M ihajlo Manojlov Cc: misc@openbsd.org Subject: Re: sasyncd syncs only newly created sad's Hi Mihajlo Yes, this feature (re-sychronization after master failure) has been missing from the day sasyncd came out (http://archives.neohapsis.com/archives/openbsd/2005-09/0818.html). When I gave that speech in Switzerland (the one you found the PDF of), I was confident that it would be implemented within a couple of months or so ... the whole thing being a sponsored development, I figured that the sponsor would want this program to be usable. But, alas, it wasn't. Pity, really. With a little more time at my hands and a little more wit in my brains I would love to pick this up. It would be SUCH a killer application. Hakan Olsson, the original developper, did once say he would look into it, butI haven't heard of him since. krgds & sorrynohelphere /markus Mihajlo Manojlov wrote: > Hi again, > > there is no feedback.. could someone who runs sasyncd check this for me? > Please, just restart sasyncd on slave(or master), and see if it syncs the > SAD's? > > This behaviour renders my redundant routers - non redundant. If I reboot > master, when it comes back and become master again, all VPN tunnels are down > because no SAD's are synced. > > Thank you very much. > > -Original Message- > From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of > Mihajlo Manojlov > Sent: Wednesday, January 06, 2010 11:10 PM > To: misc@openbsd.org > Subject: sasyncd syncs only newly created sad's > > Hi to all, > > I have two carped boxes and I want to use sasyncd for vpn redundancy, but > only > newly created sad's get synced. For example, I reboot the slave box, and when > it comes up again, sasyncd only sets flows, not the sad's. Maybe this is > normal behaviour? > > log from master: > Jan 6 21:59:23 openbsd1 sasyncd[25895]: net: peer "10.23.6.2" connected > Jan 6 21:59:23 openbsd1 sasyncd[25895]: net_ctl: peer "10.23.6.2" state > change to SLAVE > Jan 6 21:59:25 openbsd1 sasyncd[25895]: monitor_get_pfkey_snap: got 2016 > bytes SADB, 1392 bytes SPD > Jan 6 21:59:25 openbsd1 sasyncd[25895]: pfkey_send_flush: sending FLUSH to > peer 10.23.6.2 > Jan 6 21:59:25 openbsd1 sasyncd[25895]: pfkey_snapshot: SADB data > 020a00023f000200010088f180d710010303040004000200 > 15f7444b04000400 > 380404000300 > b00403000500100259d44c6d > 03000600100259d45bb205000a00 > 010038392e3231322e37362e3130392f3332 > 05000b00010038392e3231322e39312e3137382f3332 > 04000800a0009884229af8684722ecf09bfe79c0d8eef96b3cfb > 04000900c000e73eb8f1c43d90bdfaf40fb3abfe879d28e74cf8e870dd0b01001400 > 01010
Re: Mini PCI Wireless Card
Hi, what would you like to do with wifi? do you want to build an access point, or do you just want to connect to wifi network? on this link, you can see which cards support Host AP mode: http://zythmer.acyclic.org/articles/OpenBSD_4.3_wifi.html For Soekris image, I would recommend you to install it yourself. All you have to do is to boot soekris with the card you wish to install to, check C/H/S settings and write them down, then put the card in your PC, boot OpenBSD cd, in disklabel set C/H/S to the values you read before, and then install like normal. I have done that on the pc-engines wrap box, but I think the same applies to soekris too. bye -Original Message- From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of Benjamin Adams Sent: Tuesday, January 12, 2010 4:27 AM To: Luis Useche Cc: misc Subject: Re: Mini PCI Wireless Card Thanks will order one. Anyone have an img file for soekris net5501? Or where I can download one. Easier install. Thanks Ben On Mon, Jan 11, 2010 at 9:45 PM, Luis Useche wrote: > I'm using an Intel PRO/Wireless 3945ABG successfully. > > Luis > > > > On Mon, Jan 11, 2010 at 9:25 PM, Benjamin Adams wrote: >> Anyone know a good card with 4.6 support? >> Thanks >> >> Ben
Re: sasyncd syncs only newly created sad's
Hi again, there is no feedback.. could someone who runs sasyncd check this for me? Please, just restart sasyncd on slave(or master), and see if it syncs the SAD's? This behaviour renders my redundant routers - non redundant. If I reboot master, when it comes back and become master again, all VPN tunnels are down because no SAD's are synced. Thank you very much. -Original Message- From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of Mihajlo Manojlov Sent: Wednesday, January 06, 2010 11:10 PM To: misc@openbsd.org Subject: sasyncd syncs only newly created sad's Hi to all, I have two carped boxes and I want to use sasyncd for vpn redundancy, but only newly created sad's get synced. For example, I reboot the slave box, and when it comes up again, sasyncd only sets flows, not the sad's. Maybe this is normal behaviour? log from master: Jan 6 21:59:23 openbsd1 sasyncd[25895]: net: peer "10.23.6.2" connected Jan 6 21:59:23 openbsd1 sasyncd[25895]: net_ctl: peer "10.23.6.2" state change to SLAVE Jan 6 21:59:25 openbsd1 sasyncd[25895]: monitor_get_pfkey_snap: got 2016 bytes SADB, 1392 bytes SPD Jan 6 21:59:25 openbsd1 sasyncd[25895]: pfkey_send_flush: sending FLUSH to peer 10.23.6.2 Jan 6 21:59:25 openbsd1 sasyncd[25895]: pfkey_snapshot: SADB data 020a00023f000200010088f180d710010303040004000200 15f7444b04000400 380404000300 b00403000500100259d44c6d 03000600100259d45bb205000a00 010038392e3231322e37362e3130392f3332 05000b00010038392e3231322e39312e3137382f3332 04000800a0009884229af8684722ecf09bfe79c0d8eef96b3cfb 04000900c000e73eb8f1c43d90bdfaf40fb3abfe879d28e74cf8e870dd0b01001400 0101010013000300150010020a00 030011001002ff00030016001002 0a070800030012001002ff00 0200210008007465737476706e00 Jan 6 21:59:25 openbsd1 sasyncd[25895]: pfkey_snapshot: sync SA 0x88cca800 len 504 to peer 10.23.6.2 Jan 6 21:59:25 openbsd1 sasyncd[25895]: pfkey_snapshot: sync SA 0x88cca9f8 len 504 to peer 10.23.6.2 Jan 6 21:59:25 openbsd1 sasyncd[25895]: pfkey_snapshot: sync SA 0x88ccabf0 len 504 to peer 10.23.6.2 Jan 6 21:59:25 openbsd1 sasyncd[25895]: pfkey_snapshot: sync SA 0x88ccade8 len 504 to peer 10.23.6.2 Jan 6 21:59:25 openbsd1 sasyncd[25895]: pfkey_snapshot: SPD data 02121d0003000600100259d44c6d 010014000101010013000300150010020a00 030011001002ff0003001600 10020a070800030012001002ff00 05000a00010038392e3231322e39312e3137 382f333205000b00010038392e3231322e37 362e3130392f333202121d0003000600 100259d44c6d01001400030201001300 0300150010020a070800030011001002 ff000300160010020a00 030012001002ff0005000a000100 38392e3231322e39312e3137382f333205000b000100 38392e3231322e37362e3130392f33320212 Jan 6 21:59:25 openbsd1 sasyncd[25895]: pfkey_snapshot: sync FLOW 0x88cca000 len 232 to peer 10.23.6.2 Jan 6 21:59:25 openbsd1 sasyncd[25895]: pfkey_snapshot: sync FLOW 0x88cca0e8 len 232 to peer 10.23.6.2 Jan 6 21:59:25 openbsd1 sasyncd[25895]: pfkey_snapshot: sync FLOW 0x88cca1d0 len 232 to peer 10.23.6.2 Jan 6 21:59:25 openbsd1 sasyncd[25895]: pfkey_snapshot: sync FLOW 0x88cca2b8 len 232 to peer 10.23.6.2 Jan 6 21:59:25 openbsd1 sasyncd[25895]: pfkey_snapshot: sync FLOW 0x88cca3a0 len 232 to peer 10.23.6.2 Jan 6 21:59:25 openbsd1 sasyncd[25895]: pfkey_snapshot: sync FLOW 0x88cca488 len 232 to peer 10.23.6.2 It looks to me like everything is ok? log from slave: Jan 6 22:52:09 openbsd2 sasyncd[3384]: config: add peer 10.23.6.3 Jan 6 22:52:09 openbsd2 sasyncd[3384]: config: interface carp3 Jan 6 22:52:09 openbsd2 sasyncd[3384]: config: group carp Jan 6 22:52:09 openbsd2 sasyncd[3384]: config: 32 byte shared hex key Jan 6 22:52:09 openbsd2 sasyncd[3384]: config: shared key set Jan 6 22:52:09 openbsd2 sasyncd[3384]: carp_init: initializing runstate to SLAVE Jan 6 22:52:09 openbsd2 sasyncd[3384]: listening on 0.0.0.0 port 500 fd 6 Jan 6 22:52:09 openbsd2 sasyncd[3384]: net_connect: peer "10.23.6.3" connected, fd 7 Jan 6 22:52:09 openbsd2
sasyncd syncs only newly created sad's
Hi to all, I have two carped boxes and I want to use sasyncd for vpn redundancy, but only newly created sad's get synced. For example, I reboot the slave box, and when it comes up again, sasyncd only sets flows, not the sad's. Maybe this is normal behaviour? log from master: Jan 6 21:59:23 openbsd1 sasyncd[25895]: net: peer "10.23.6.2" connected Jan 6 21:59:23 openbsd1 sasyncd[25895]: net_ctl: peer "10.23.6.2" state change to SLAVE Jan 6 21:59:25 openbsd1 sasyncd[25895]: monitor_get_pfkey_snap: got 2016 bytes SADB, 1392 bytes SPD Jan 6 21:59:25 openbsd1 sasyncd[25895]: pfkey_send_flush: sending FLUSH to peer 10.23.6.2 Jan 6 21:59:25 openbsd1 sasyncd[25895]: pfkey_snapshot: SADB data 020a00023f000200010088f180d710010303040004000200 15f7444b04000400 380404000300 b00403000500100259d44c6d 03000600100259d45bb205000a00 010038392e3231322e37362e3130392f3332 05000b00010038392e3231322e39312e3137382f3332 04000800a0009884229af8684722ecf09bfe79c0d8eef96b3cfb 04000900c000e73eb8f1c43d90bdfaf40fb3abfe879d28e74cf8e870dd0b01001400 0101010013000300150010020a00 030011001002ff00030016001002 0a070800030012001002ff00 0200210008007465737476706e00 Jan 6 21:59:25 openbsd1 sasyncd[25895]: pfkey_snapshot: sync SA 0x88cca800 len 504 to peer 10.23.6.2 Jan 6 21:59:25 openbsd1 sasyncd[25895]: pfkey_snapshot: sync SA 0x88cca9f8 len 504 to peer 10.23.6.2 Jan 6 21:59:25 openbsd1 sasyncd[25895]: pfkey_snapshot: sync SA 0x88ccabf0 len 504 to peer 10.23.6.2 Jan 6 21:59:25 openbsd1 sasyncd[25895]: pfkey_snapshot: sync SA 0x88ccade8 len 504 to peer 10.23.6.2 Jan 6 21:59:25 openbsd1 sasyncd[25895]: pfkey_snapshot: SPD data 02121d0003000600100259d44c6d 010014000101010013000300150010020a00 030011001002ff0003001600 10020a070800030012001002ff00 05000a00010038392e3231322e39312e3137 382f333205000b00010038392e3231322e37 362e3130392f333202121d0003000600 100259d44c6d01001400030201001300 0300150010020a070800030011001002 ff000300160010020a00 030012001002ff0005000a000100 38392e3231322e39312e3137382f333205000b000100 38392e3231322e37362e3130392f33320212 Jan 6 21:59:25 openbsd1 sasyncd[25895]: pfkey_snapshot: sync FLOW 0x88cca000 len 232 to peer 10.23.6.2 Jan 6 21:59:25 openbsd1 sasyncd[25895]: pfkey_snapshot: sync FLOW 0x88cca0e8 len 232 to peer 10.23.6.2 Jan 6 21:59:25 openbsd1 sasyncd[25895]: pfkey_snapshot: sync FLOW 0x88cca1d0 len 232 to peer 10.23.6.2 Jan 6 21:59:25 openbsd1 sasyncd[25895]: pfkey_snapshot: sync FLOW 0x88cca2b8 len 232 to peer 10.23.6.2 Jan 6 21:59:25 openbsd1 sasyncd[25895]: pfkey_snapshot: sync FLOW 0x88cca3a0 len 232 to peer 10.23.6.2 Jan 6 21:59:25 openbsd1 sasyncd[25895]: pfkey_snapshot: sync FLOW 0x88cca488 len 232 to peer 10.23.6.2 It looks to me like everything is ok? log from slave: Jan 6 22:52:09 openbsd2 sasyncd[3384]: config: add peer 10.23.6.3 Jan 6 22:52:09 openbsd2 sasyncd[3384]: config: interface carp3 Jan 6 22:52:09 openbsd2 sasyncd[3384]: config: group carp Jan 6 22:52:09 openbsd2 sasyncd[3384]: config: 32 byte shared hex key Jan 6 22:52:09 openbsd2 sasyncd[3384]: config: shared key set Jan 6 22:52:09 openbsd2 sasyncd[3384]: carp_init: initializing runstate to SLAVE Jan 6 22:52:09 openbsd2 sasyncd[3384]: listening on 0.0.0.0 port 500 fd 6 Jan 6 22:52:09 openbsd2 sasyncd[3384]: net_connect: peer "10.23.6.3" connected, fd 7 Jan 6 22:52:09 openbsd2 sasyncd[26685]: net_ctl: peer "10.23.6.3" state change to MASTER Jan 6 22:52:11 openbsd2 sasyncd[26685]: pfkey_queue_message: pfkey FLUSH len 16 seq 1 Jan 6 22:52:11 openbsd2 sasyncd[26685]: pfkey_queue_message: pfkey ADD len 504 seq 2 Jan 6 22:52:11 openbsd2 sasyncd[26685]: pfkey_queue_message: pfkey ADD len 504 seq 3 Jan 6 22:52:11 openbsd2 sasyncd[26685]: pfkey: msg ADD write() failed on socket 5: Invalid argument Jan 6 22:52:11 openbsd2 sasyncd[26685]: pfkey_queue_message: pfkey ADD len 504 seq 4 Jan 6 22:52:11 openbsd2 sasyncd[26685]: pfkey: msg ADD write() failed on socket 5: Invalid argument Jan 6 22:52:11 openbsd2 sasyncd[26685]: pfk
