Re: Routing issue with VPN tunnel [SOLVED]
Hi all, The lo1 workaround worked. There are some posts out there that explain this, or parts of it, and here's my contribution. The two threads I found most helpful can be googled: "NAT on IPSEC with OpenBSD/pf/isakmpd" "OT - NAT on IPsec" The issues in question are mentioned earlier in this thread and I won't repeat them. 1 - Create a loopback interface on which NATting will be done: # cat /etc/hostname.lo1 inet 172.16.0.1 255.255.255.0 NONE description "IPsec NAT interface" This should be an ip of a different subnet than your internal network. 2 - Add a static route to the remote network you are trying to reach: route add 192.168.0.0/24 172.16.0.1 3 - Configure lo1 for nat (pf.conf): nat on lo1 from $internal_net to 192.168.0.0/24 -> lo1 4 - Create pf.conf rules: ## ISAKMP VPN pass on lo1 inet from lo1 to 192.168.0.0/24 keep state # In pass in on enc0 keep state (if-bound) # Out pass out on enc0 inet from lo1 to 192.168.0.0/24 pass on enc0 proto ipencap all keep state (if-bound) pass on $ext_if inet proto esp all keep state --- NB. Outgoing enc0 traffic rule must not contain "keep state" 5 - The ipsec tunnel/flows must of course be added with 172.16.0.1 as IPV4_ADDR. [My-Net] ID-Type=IPV4_ADDR Address= 172.16.0.1 Best regards, Danial
Re: Routing issue with VPN tunnel
On Dec 17, 2008 1:14am, Boris Goldberg wrote: > Hello Danial, > > > > Tuesday, December 16, 2008, 6:55:17 PM, you wrote: > > > > DO> This involves the same issue as mentioned earlier, that the > > DO> flows/"dummy tunnel" does in fact get transmitted to the peer for > > DO> quick mode negotiation. > > > > Yes it does, but why do you care? Does the "real" tunnel stop working > > because of that? No it doesn't, but the remote site doesn't accept anything but my specific ip address. So it restricts me from creating additional "broader" flows. I'm gonna try the aforementioned lo1 hack as soon as they allow the new ip I'm gonna use for NAT. / Danial
Re: Routing issue with VPN tunnel
On Tue, Dec 16, 2008 at 11:17 PM, Boris Goldberg wrote: > Hello Danial, > > Tuesday, December 16, 2008, 4:07:26 PM, you wrote: > >>> Your tunnel is probably host-to-host - don't change it, but add an >>> additional network-to-host one. That "dummy" tunnel wont actually transfer >>> anything, but will route packets from your internal network to enc0, than >>> your nat rule will change it and everything should work. > > DO> I'm not quite sure how you've done this. Could you be more specific? > DO> Do you mean to add an additional Connection in isakmpd.conf and refer > DO> to the same Peer but a different network (Local-ID)? > > Yes, something like the following: > > [Phase 1] > =PIX > > [Phase 2] > Connections=PIX_CONN-1,PIX_CONN-1_1 > > [PIX_CONN-1] > Phase= 2 > ISAKMP-peer=PIX > Configuration= quick-mode-pix > Local-ID= Net-twopoint > Remote-ID= pix-internal-1 > > [PIX_CONN-1_1] > Phase= 2 > ISAKMP-peer=PIX > Configuration= quick-mode-pix > Local-ID= twopoint-internal-1 > Remote-ID= pix-internal-1 > > [Net-twopoint] > ID-type=IPV4_ADDR_SUBNET > Network= > Netmask= > > [twopoint-internal-1] > ID-type= IPV4_ADDR > Address= > > [pix-internal-1] > ID-type= IPV4_ADDR > Address= > > Of course, it's just a quote from our isakmd.conf. Real numbers are > substituted with . This involves the same issue as mentioned earlier, that the flows/"dummy tunnel" does in fact get transmitted to the peer for quick mode negotiation. isakmpd -dvL reports Default transport_send_messages: giving up on exchange PEER, no response from peer :500 isakmpd.pcap contains 00:38:55.138549 .500 > .500: [udp sum ok] isakmp v1.0 exchange QUICK_MODE cookie: 4e4b2944370a8560->ff879e6d83275fd5 msgid: 85e8f8bd len: 284 payload: HASH len: 24 payload: SA len: 52 DOI: 1(IPSEC) situation: IDENTITY_ONLY payload: PROPOSAL len: 40 proposal: 1 proto: IPSEC_ESP spisz: 4 xforms: 1 SPI: 0x8f05b4fc payload: TRANSFORM len: 28 transform: 1 ID: 3DES attribute LIFE_TYPE = SECONDS attribute LIFE_DURATION = 1200 attribute ENCAPSULATION_MODE = TUNNEL attribute AUTHENTICATION_ALGORITHM = HMAC_SHA attribute GROUP_DESCRIPTION = 2 payload: NONCE len: 20 payload: KEY_EXCH len: 132 payload: ID len: 16 type: IPV4_ADDR_SUBNET = /255.255.0.0 payload: ID len: 12 type: IPV4_ADDR = [ttl 0] (id 1, len 312) 00:38:55.218317 .500 > .500: [udp sum ok] isakmp v1.0 exchange INFO cookie: 4e4b2944370a8560->ff879e6d83275fd5 msgid: c2905b70 len: 124 payload: HASH len: 24 payload: NOTIFICATION len: 68 notification: NO PROPOSAL CHOSEN [ttl 0] (id 1, len 152) I'm relying on the lo1 hack to save me. Gonna try it as soon as the IP I'm gonna use gets accepted by the remote site! Thanks, Danial
Re: Routing issue with VPN tunnel
On Tue, Dec 16, 2008 at 3:02 PM, Boris Goldberg wrote: > Hello Danial, > > Sunday, December 14, 2008, 6:06:12 PM, you wrote: > > D> The remote tunnel endpoint expects traffic originating from > D> a specific ip address - the internal ip of the firewall. > >>> I have a tunnel successfully set up between my OpenBSD 3.8 >>> and a Cisco 7200 router. >>> ... >>> There are ACLs on the $remote_gw which only allow traffic >>> NATed with my $int_if ip. Hence this nat in pf.conf: >>> nat on enc0 inet from $int_net to $remote_host -> $int_if >>> ... >>> What I CAN do is ping the $remote_host through the tunnel >>> from the $int_if with the following command: >>> # ping -I $int_if $remote_host >>> >>> This works and replies are received! >>> >>> >>> But if if try pinging from the $internal_host: >>> c:\> ping $remote_host >>> >>> This doesn't work. The packets are not sent through the >>> tunnel but to the internet. > > I have a working tunnel like yours. May be there is a way to do it > "right", but I haven't found one. But here is a workaround: A workaround is just fine by me :) > Your tunnel is probably host-to-host - don't change it, but add an > additional network-to-host one. That "dummy" tunnel wont actually transfer > anything, but will route packets from your internal network to enc0, than > your nat rule will change it and everything should work. I'm not quite sure how you've done this. Could you be more specific? Do you mean to add an additional Connection in isakmpd.conf and refer to the same Peer but a different network (Local-ID)? Thanks for your reply, Danial
Re: Routing issue with VPN tunnel
Hello Danial, Sunday, December 14, 2008, 6:06:12 PM, you wrote: D> The remote tunnel endpoint expects traffic originating from D> a specific ip address - the internal ip of the firewall. >> I have a tunnel successfully set up between my OpenBSD 3.8 >> and a Cisco 7200 router. >> ... >> There are ACLs on the $remote_gw which only allow traffic >> NATed with my $int_if ip. Hence this nat in pf.conf: >> nat on enc0 inet from $int_net to $remote_host -> $int_if >> ... >> What I CAN do is ping the $remote_host through the tunnel >> from the $int_if with the following command: >> # ping -I $int_if $remote_host >> >> This works and replies are received! >> >> >> But if if try pinging from the $internal_host: >> c:\> ping $remote_host >> >> This doesn't work. The packets are not sent through the >> tunnel but to the internet. I have a working tunnel like yours. May be there is a way to do it "right", but I haven't found one. But here is a workaround: Your tunnel is probably host-to-host - don't change it, but add an additional network-to-host one. That "dummy" tunnel wont actually transfer anything, but will route packets from your internal network to enc0, than your nat rule will change it and everything should work. -- Best regards, Borismailto:bo...@twopoint.com
Re: Routing issue with VPN tunnel
On 2008-12-15, Danial Olsen wrote: > Is it possible to nat incoming traffic? no. but there is some hack involving lo1, try google: lo1 nat enc0 >> b) add more flows, mainly >> flow esp out from $int_net to $remote_host peer $remote_gw > > Also tried this. The problem is that the flows are negotiated with the > remote host and it rejects them. Does the remote host really have to > know? hmm, I think there's a diff floating around for this...
Re: Routing issue with VPN tunnel
On Mon, Dec 15, 2008 at 8:46 AM, Claudio Jeker wrote: > On Mon, Dec 15, 2008 at 12:06:12AM +, Danial wrote: >> I don't like responding to my own thread but I really need >> help with this one, so I'll try to rephrase the question: >> >> The remote tunnel endpoint expects traffic originating from >> a specific ip address - the internal ip of the firewall. >> >> How can I achieve this? >> > > I think your setup is worng. See inline. > >> >> On Tue, Dec 9, 2008 at 1:11 PM, do wrote: >> > Hello, >> > >> > I'm having some problems routing traffic through a isakmp >> > vpn tunnel. >> > >> > I have a tunnel successfully set up between my OpenBSD 3.8 >> > and a Cisco 7200 router. >> > I'm not good at ascii art, but here's how I see it: >> > >> > $int_if = 10.0.0.1 >> > $remote_host = 192.168.0.1 >> > >> > >> > $int_if <> enc0 <> $ext_if |> (internet) >> > | |=>$remote_gw<-->$remote_host >> > | >> > | >> > $internal_host >> > >> > >> > >> > There are ACLs on the $remote_gw which only allow traffic >> > NATed with my $int_if ip. Hence this nat in pf.conf: >> > nat on enc0 inet from $int_net to $remote_host -> $int_if >> > > > This nat rule is kicking in to late. Your flow setup will only match > traffic from $int_if to $remote_host. Now even if your default route is > pointing to the $remote_host the traffic from your internal lan will not > match the flow and not end up on enc0. > > I see two possible fixes: > a) nat on the internal interface so that incomming traffic is already > showing up as comming from $inf_if Is it possible to nat incoming traffic? I've tried this but can't seem to get it to work. I can only seem to nat outgoing traffic. > b) add more flows, mainly > flow esp out from $int_net to $remote_host peer $remote_gw Also tried this. The problem is that the flows are negotiated with the remote host and it rejects them. Does the remote host really have to know? > >> > >> > I've established that the flows exist: >> > # netstat -rn -f encap >> > $remote_host/32 0 $int_if/32 0 0 >> > $remote_gw/50/use/in >> > $int_if/32 0 $remote_host/32 0 0 >> > $remote_gw/50/require/out >> > >> > # ipsecctl -s flow >> > flow esp in from $remote_host to $int_if peer $remote_gw >> > flow esp out from $int_if to $remote_host peer $remote_gw >> > >> > >> > What I CAN do is ping the $remote_host through the tunnel >> > from the $int_if with the following command: >> > # ping -I $int_if $remote_host >> > >> > This works and replies are received! >> > >> > >> > But if if try pinging from the $internal_host: >> > c:\> ping $remote_host >> > >> > This doesn't work. The packets are not sent through the >> > tunnel but to the internet. >> > >> > >> > I've tried this route-to line in pf.conf: >> > pass in log quick on $int_if route-to enc0 from $int_net >> to >> > $remote_host keep state >> > >> > And by running tcpdump on pflog0 I can see that packets >> are >> > matched: >> > rule 16/(match) pass out on enc0: $int_if > $remote_host: >> > icmp: echo request >> > >> > But no traffic is sent through the tunnel. >> > >> > >> > Why are pings sent from the $internal_host not matched to >> > the flow/route and sent through the corresponding tunnel? >> > >> > Any help is appreciated in resolving this issue! >> > >> > >> > - Danial >> > > -- > :wq Claudio > > Regards, Danial
Re: Routing issue with VPN tunnel
On Mon, Dec 15, 2008 at 12:06:12AM +, Danial wrote: > I don't like responding to my own thread but I really need > help with this one, so I'll try to rephrase the question: > > The remote tunnel endpoint expects traffic originating from > a specific ip address - the internal ip of the firewall. > > How can I achieve this? > I think your setup is worng. See inline. > > On Tue, Dec 9, 2008 at 1:11 PM, do wrote: > > Hello, > > > > I'm having some problems routing traffic through a isakmp > > vpn tunnel. > > > > I have a tunnel successfully set up between my OpenBSD 3.8 > > and a Cisco 7200 router. > > I'm not good at ascii art, but here's how I see it: > > > > $int_if = 10.0.0.1 > > $remote_host = 192.168.0.1 > > > > > > $int_if <> enc0 <> $ext_if |> (internet) > > | |> $remote_gw <--> > $remote_host > > | > > | > > $internal_host > > > > > > > > There are ACLs on the $remote_gw which only allow traffic > > NATed with my $int_if ip. Hence this nat in pf.conf: > > nat on enc0 inet from $int_net to $remote_host -> $int_if > > This nat rule is kicking in to late. Your flow setup will only match traffic from $int_if to $remote_host. Now even if your default route is pointing to the $remote_host the traffic from your internal lan will not match the flow and not end up on enc0. I see two possible fixes: a) nat on the internal interface so that incomming traffic is already showing up as comming from $inf_if b) add more flows, mainly flow esp out from $int_net to $remote_host peer $remote_gw > > > > I've established that the flows exist: > > # netstat -rn -f encap > > $remote_host/32 0 $int_if/32 0 0 > > $remote_gw/50/use/in > > $int_if/32 0 $remote_host/32 0 0 > > $remote_gw/50/require/out > > > > # ipsecctl -s flow > > flow esp in from $remote_host to $int_if peer $remote_gw > > flow esp out from $int_if to $remote_host peer $remote_gw > > > > > > What I CAN do is ping the $remote_host through the tunnel > > from the $int_if with the following command: > > # ping -I $int_if $remote_host > > > > This works and replies are received! > > > > > > But if if try pinging from the $internal_host: > > c:\> ping $remote_host > > > > This doesn't work. The packets are not sent through the > > tunnel but to the internet. > > > > > > I've tried this route-to line in pf.conf: > > pass in log quick on $int_if route-to enc0 from $int_net > to > > $remote_host keep state > > > > And by running tcpdump on pflog0 I can see that packets > are > > matched: > > rule 16/(match) pass out on enc0: $int_if > $remote_host: > > icmp: echo request > > > > But no traffic is sent through the tunnel. > > > > > > Why are pings sent from the $internal_host not matched to > > the flow/route and sent through the corresponding tunnel? > > > > Any help is appreciated in resolving this issue! > > > > > > - Danial > -- :wq Claudio
Re: Routing issue with VPN tunnel
On Mon, 2008-12-15 at 00:06 +, Danial wrote: > I don't like responding to my own thread but I really need > help with this one, so I'll try to rephrase the question: Just about every userland utility has the ability to specify source transmit addresses (bind(4) function) If not, we can add it. It's probably the second-most-asked question on the Net-SNMP mailing lists (because of all of the embedding, likely) ~BAS > > The remote tunnel endpoint expects traffic originating from IMPORTANT: This message contains confidential information and is intended only for the individual named. If the reader of this message is not an intended recipient (or the individual responsible for the delivery of this message to an intended recipient), please be advised that any re-use, dissemination, distribution or copying of this message is prohibited. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system.
Re: Routing issue with VPN tunnel
I don't like responding to my own thread but I really need help with this one, so I'll try to rephrase the question: The remote tunnel endpoint expects traffic originating from a specific ip address - the internal ip of the firewall. How can I achieve this? / Danial On Tue, Dec 9, 2008 at 1:11 PM, do wrote: > Hello, > > I'm having some problems routing traffic through a isakmp > vpn tunnel. > > I have a tunnel successfully set up between my OpenBSD 3.8 > and a Cisco 7200 router. > I'm not good at ascii art, but here's how I see it: > > $int_if = 10.0.0.1 > $remote_host = 192.168.0.1 > > > $int_if <> enc0 <> $ext_if |> (internet) > | |> $remote_gw <--> $remote_host > | > | > $internal_host > > > > There are ACLs on the $remote_gw which only allow traffic > NATed with my $int_if ip. Hence this nat in pf.conf: > nat on enc0 inet from $int_net to $remote_host -> $int_if > > > I've established that the flows exist: > # netstat -rn -f encap > $remote_host/32 0 $int_if/32 0 0 > $remote_gw/50/use/in > $int_if/32 0 $remote_host/32 0 0 > $remote_gw/50/require/out > > # ipsecctl -s flow > flow esp in from $remote_host to $int_if peer $remote_gw > flow esp out from $int_if to $remote_host peer $remote_gw > > > What I CAN do is ping the $remote_host through the tunnel > from the $int_if with the following command: > # ping -I $int_if $remote_host > > This works and replies are received! > > > But if if try pinging from the $internal_host: > c:\> ping $remote_host > > This doesn't work. The packets are not sent through the > tunnel but to the internet. > > > I've tried this route-to line in pf.conf: > pass in log quick on $int_if route-to enc0 from $int_net to > $remote_host keep state > > And by running tcpdump on pflog0 I can see that packets are > matched: > rule 16/(match) pass out on enc0: $int_if > $remote_host: > icmp: echo request > > But no traffic is sent through the tunnel. > > > Why are pings sent from the $internal_host not matched to > the flow/route and sent through the corresponding tunnel? > > Any help is appreciated in resolving this issue! > > > - Danial
