Routing issue with VPN tunnel

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

Routing issue with VPN tunnel

do-16
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

Reply | Threaded
Open this post in threaded view
|

Re: Routing issue with VPN tunnel

do-16
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 <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: Routing issue with VPN tunnel

bseklecki-2
On Mon, 2008-12-15 at 00:06 +0000, 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.

Reply | Threaded
Open this post in threaded view
|

Re: Routing issue with VPN tunnel

Claudio Jeker
In reply to this post by do-16
On Mon, Dec 15, 2008 at 12:06:12AM +0000, 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 <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: Routing issue with VPN tunnel

danial
On Mon, Dec 15, 2008 at 8:46 AM, Claudio Jeker <[hidden email]> wrote:

> On Mon, Dec 15, 2008 at 12:06:12AM +0000, 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 <[hidden email]> 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

/ Danial
Reply | Threaded
Open this post in threaded view
|

Re: Routing issue with VPN tunnel

Stuart Henderson
On 2008-12-15, Danial Olsen <[hidden email]> 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...

Reply | Threaded
Open this post in threaded view
|

Re: Routing issue with VPN tunnel

Boris Goldberg
In reply to this post by do-16
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,
 Boris                            mailto:[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Routing issue with VPN tunnel

danial
On Tue, Dec 16, 2008 at 3:02 PM, Boris Goldberg <[hidden email]> 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

/ Danial
Reply | Threaded
Open this post in threaded view
|

Re: Routing issue with VPN tunnel

danial
In reply to this post by Boris Goldberg
On Tue, Dec 16, 2008 at 11:17 PM, Boris Goldberg <[hidden email]> 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]
> <their_external_IP>=    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=                <our_network>
> Netmask=                <our_netmask>
>
> [twopoint-internal-1]
> ID-type=               IPV4_ADDR
> Address=               <our_firewall_internal_IP>
>
> [pix-internal-1]
> ID-type=               IPV4_ADDR
> Address=               <their_box_internal_IP>
>
>  Of course, it's just a quote from our isakmd.conf. Real numbers are
> substituted with <description>.

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 <peer_ip>:500

isakmpd.pcap contains
00:38:55.138549 <myhostip>.500 > <peer_ip>.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 = <my_lan>/255.255.0.0
        payload: ID len: 12 type: IPV4_ADDR = <remote_internal_ip>
[ttl 0] (id 1, len 312)
00:38:55.218317 <peer_ip>.500 > <myhostip>.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

/ Danial
Reply | Threaded
Open this post in threaded view
|

Re: Routing issue with VPN tunnel

danial
In reply to this post by do-16
On Dec 17, 2008 1:14am, Boris Goldberg <[hidden email]> 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


/ Danial