IPSec VPNs when traffic originates from a daemon on the OBSD firewall

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

IPSec VPNs when traffic originates from a daemon on the OBSD firewall

Andy Lemin
Hi misc,

We have what should be a simple VPN routing issue but I can't figure out
what to do with the IPSec config. We have many remote office firewalls
with IPSec tunnels linking to our head office (hub and spoke topology),
each defining Phase 2 policies mapping the remote internal networks to
the head office internal network.

Traffic flows perfectly from local LAN to remote LAN and visa-versa. But
I am stuck as to how to configure the tunnels so a daemon on the remote
OBSD firewalls themselves can route traffic to the head office internal LAN.

To be specific I have written a script which analyses the interface HFSC
queues from 'systat queues' etc, and then 'netcats' the formatted data
(throughput rates etc) to our statsd/graphite server for display. It
works really well on the head office firewalls which netcat the rates
etc to the internal statsd/graphite server which is on the internal LAN,
however when running the same script on the remote office firewalls, I
have the problem of how to get the netcat payload down the IPSec tunnel
to the head office LAN.

When I try to do a ping or otherwise on the remote firewalls to the head
office lan, I get a 'no route to host' error which implies that the
IPSec vpn policy route which can be seen in the 'route show' is not
being used as the source IP of the ping/payload is not going to have the
firewalls internal LAN addres to match the policy route etc..

I was thinking about packet tagging, or doing some kind of dirty
mangling of sorts, but not sure?

Thanks for your thoughts :)

Andrew Lemin

Reply | Threaded
Open this post in threaded view
|

Re: IPSec VPNs when traffic originates from a daemon on the OBSD firewall

Anders Berggren-2
> When I try to do a ping or otherwise on the remote firewalls to the head office lan, I get a 'no route to host' error which implies that the IPSec vpn policy route which can be seen in the 'route show' is not being used as the source IP of the ping/payload is not going to have the firewalls internal LAN addres to match the policy route etc..

Perhaps you've created flows from our LAN network range only? If so, for a ping to work, you need to specify the local IP, like

ping -I 192.168.1.1 192.168.2.1

Make sure you originate the traffic from an IP included in the flow specification.

Reply | Threaded
Open this post in threaded view
|

Re: IPSec VPNs when traffic originates from a daemon on the OBSD firewall

Andy Lemin
Hi, Yes that does work and is the problem as mentioned, but I don't
know how to change the source address for the 'netcat' command payload?

Ping was just a test to see what is going on..

Cheers, Andy.

On Thu 04 Jul 2013 14:08:41 BST, Anders Berggren wrote:
>> When I try to do a ping or otherwise on the remote firewalls to the head office lan, I get a 'no route to host' error which implies that the IPSec vpn policy route which can be seen in the 'route show' is not being used as the source IP of the ping/payload is not going to have the firewalls internal LAN addres to match the policy route etc..
>
> Perhaps you've created flows from our LAN network range only? If so, for a ping to work, you need to specify the local IP, like
>
> ping -I 192.168.1.1 192.168.2.1
>
> Make sure you originate the traffic from an IP included in the flow specification.

Reply | Threaded
Open this post in threaded view
|

Re: IPSec VPNs when traffic originates from a daemon on the OBSD firewall

Anders Berggren-2
>> Perhaps you've created flows from our LAN network range only? If so, for a ping to work, you need to specify the local IP, like
>> ping -I 192.168.1.1 192.168.2.1
> how to change the source address for the 'netcat' command payload?

According to http://www.openbsd.org/cgi-bin/man.cgi?query=nc it has a similar flag, -l

nc -l 192.168.1.1 192.168.2.1

Reply | Threaded
Open this post in threaded view
|

Re: IPSec VPNs when traffic originates from a daemon on the OBSD firewall

Anders Berggren-2
>>> Perhaps you've created flows from our LAN network range only? If so, for a ping to work, you need to specify the local IP, like
>>> ping -I 192.168.1.1 192.168.2.1
>> how to change the source address for the 'netcat' command payload?
> According to http://www.openbsd.org/cgi-bin/man.cgi?query=nc it has a similar flag, -l

I was too quick, it is -s

nc -s 192.168.1.1 192.168.2.1

Reply | Threaded
Open this post in threaded view
|

Re: IPSec VPNs when traffic originates from a daemon on the OBSD firewall

Andy Lemin
In reply to this post by Anders Berggren-2
PS; Its also not limited to netcat (if it were I would just use the -s
switch on netcat)..

I have other daemons on the remote firewalls that I need to also 'phone
home', and so I believe I need to do it by either changing/adding the
VPN policies or packet mangling with PF..

I'd rather not have to create extra tunnels or define VPN policies with
subnets which have prefixes wider than the internal LANs.

That leaves mangling, but I cannot see how I would do the mangling in PF
to make it work without doing a redirect through the loopback etc.. Just
wondering if anyone knows of a cleaner way?

thanks :)

On 04/07/13 14:08, Anders Berggren wrote:
>> When I try to do a ping or otherwise on the remote firewalls to the head office lan, I get a 'no route to host' error which implies that the IPSec vpn policy route which can be seen in the 'route show' is not being used as the source IP of the ping/payload is not going to have the firewalls internal LAN addres to match the policy route etc..
> Perhaps you've created flows from our LAN network range only? If so, for a ping to work, you need to specify the local IP, like
>
> ping -I 192.168.1.1 192.168.2.1
>
> Make sure you originate the traffic from an IP included in the flow specification.

Reply | Threaded
Open this post in threaded view
|

Re: IPSec VPNs when traffic originates from a daemon on the OBSD firewall

Anders Berggren-2
> I'd rather not have to create extra tunnels or define VPN policies with subnets which have prefixes wider than the internal LANs.
> That leaves mangling, but I cannot see how I would do the mangling in PF to make it work without doing a redirect through the loopback etc.. Just wondering if anyone knows of a cleaner way?

I think widening the flow's source is cleanest (as I mentioned in my first reply). However, I think it's possible to use a gif tunnel for the tunnel encapsulation, and only use IPsec for the endpoint encryption. It would probably work, because unlike IPsec flows, it's not "source routed".

Reply | Threaded
Open this post in threaded view
|

Re: IPSec VPNs when traffic originates from a daemon on the OBSD firewall

Andy Lemin
On Thu 04 Jul 2013 15:22:55 BST, Anders Berggren wrote:
>> I'd rather not have to create extra tunnels or define VPN policies with subnets which have prefixes wider than the internal LANs.
>> That leaves mangling, but I cannot see how I would do the mangling in PF to make it work without doing a redirect through the loopback etc.. Just wondering if anyone knows of a cleaner way?
>
> I think widening the flow's source is cleanest (as I mentioned in my first reply). However, I think it's possible to use a gif tunnel for the tunnel encapsulation, and only use IPsec for the endpoint encryption. It would probably work, because unlike IPsec flows, it's not "source routed".

Ah ha!!! Of course!! Thank you :D

Andy.

Reply | Threaded
Open this post in threaded view
|

Re: IPSec VPNs when traffic originates from a daemon on the OBSD firewall

Maxim Bourmistrov-5
I use OSPFd on each OpenSBD firewall I deploy.
This way you get access to all machines on the remote LAN, including firewall itself.
and you don't have to maintain routing manually.

//mxb

On 4 jul 2013, at 16:25, Andy <[hidden email]> wrote:

> On Thu 04 Jul 2013 15:22:55 BST, Anders Berggren wrote:
>>> I'd rather not have to create extra tunnels or define VPN policies with subnets which have prefixes wider than the internal LANs.
>>> That leaves mangling, but I cannot see how I would do the mangling in PF to make it work without doing a redirect through the loopback etc.. Just wondering if anyone knows of a cleaner way?
>>
>> I think widening the flow's source is cleanest (as I mentioned in my first reply). However, I think it's possible to use a gif tunnel for the tunnel encapsulation, and only use IPsec for the endpoint encryption. It would probably work, because unlike IPsec flows, it's not "source routed".
>
> Ah ha!!! Of course!! Thank you :D
>
> Andy.

Reply | Threaded
Open this post in threaded view
|

Re: IPSec VPNs when traffic originates from a daemon on the OBSD firewall

Todd T. Fries-2
In reply to this post by Andy Lemin
Penned by Andy on 20130704  9:25.40, we have:
| On Thu 04 Jul 2013 15:22:55 BST, Anders Berggren wrote:
| >>I'd rather not have to create extra tunnels or define VPN policies with subnets which have prefixes wider than the internal LANs.
| >>That leaves mangling, but I cannot see how I would do the mangling in PF to make it work without doing a redirect through the loopback etc.. Just wondering if anyone knows of a cleaner way?
| >
| >I think widening the flow's source is cleanest (as I mentioned in my first reply). However, I think it's possible to use a gif tunnel for the tunnel encapsulation, and only use IPsec for the endpoint encryption. It would probably work, because unlike IPsec flows, it's not "source routed".
|
| Ah ha!!! Of course!! Thank you :D
|
| Andy.

The other option is to add a local route that seems pointless but actually aids in the scenario.

Consider a router with an internal network IP of 192.168.0.1/24.

Consider a an IPSec tunnel from 192.168.0.0/24 <-> 192.168.1.0/24.

Consider adding a route 'route add 192.168.1.0/24 192.168.0.1'.

Suddenly the source IP of any daemon on the OpenBSD system becomes
192.168.0.1 when attempting to connect to any system on the
192.168.1.0/24 segment.

This trick only works for IPv4.  For IPv6, there is no solution beyond
having each software choose its source address carefully.

FWIW.
--
Todd Fries .. [hidden email]

 ____________________________________________
|                                            \  1.636.410.0632 (voice)
| Free Daemon Consulting, LLC                \  1.405.227.9094 (voice)
| http://FreeDaemonConsulting.com            \  1.866.792.3418 (FAX)
| PO Box 16169, Oklahoma City, OK 73113-2169 \  sip:[hidden email]
| "..in support of free software solutions." \  sip:[hidden email]
 \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
                                                 
              37E7 D3EB 74D0 8D66 A68D  B866 0326 204E 3F42 004A
                        http://todd.fries.net/pgp.txt

Reply | Threaded
Open this post in threaded view
|

Re: IPSec VPNs when traffic originates from a daemon on the OBSD firewall

Andy Lemin
I don't know why, but for some reason it just didn't occur to me that
doing that would set the source IP but of course it would. Hand -> Face
slap! ;)

Thanks :)

On Fri 05 Jul 2013 11:51:39 BST, Todd T. Fries wrote:

> Penned by Andy on 20130704  9:25.40, we have:
> | On Thu 04 Jul 2013 15:22:55 BST, Anders Berggren wrote:
> | >>I'd rather not have to create extra tunnels or define VPN policies with subnets which have prefixes wider than the internal LANs.
> | >>That leaves mangling, but I cannot see how I would do the mangling in PF to make it work without doing a redirect through the loopback etc.. Just wondering if anyone knows of a cleaner way?
> | >
> | >I think widening the flow's source is cleanest (as I mentioned in my first reply). However, I think it's possible to use a gif tunnel for the tunnel encapsulation, and only use IPsec for the endpoint encryption. It would probably work, because unlike IPsec flows, it's not "source routed".
> |
> | Ah ha!!! Of course!! Thank you :D
> |
> | Andy.
>
> The other option is to add a local route that seems pointless but actually aids in the scenario.
>
> Consider a router with an internal network IP of 192.168.0.1/24.
>
> Consider a an IPSec tunnel from 192.168.0.0/24 <-> 192.168.1.0/24.
>
> Consider adding a route 'route add 192.168.1.0/24 192.168.0.1'.
>
> Suddenly the source IP of any daemon on the OpenBSD system becomes
> 192.168.0.1 when attempting to connect to any system on the
> 192.168.1.0/24 segment.
>
> This trick only works for IPv4.  For IPv6, there is no solution beyond
> having each software choose its source address carefully.
>
> FWIW.

Reply | Threaded
Open this post in threaded view
|

Re: IPSec VPNs when traffic originates from a daemon on the OBSD firewall

Stuart Henderson
In reply to this post by Anders Berggren-2
On 2013-07-04, Anders Berggren <[hidden email]> wrote:
>               However, I think it's possible to use a gif tunnel for the
> tunnel encapsulation, and only use IPsec for the endpoint encryption.
> It would probably work, because unlike IPsec flows, it's not "source
> routed".

Matt Dainty got this to work with manual keying.

http://bodgitandscarper.co.uk/openbsd/openbsd-ipsec-and-rfc-3884/

Additional work on the daemons would be needed to support this with
either IKE or IKEv2.