Re: IPSec VPNs when traffic originates from a daemon on the OBSD firewall
On 2013-07-04, Anders Berggren and...@halon.se 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.
Re: IPSec VPNs when traffic originates from a daemon on the OBSD firewall
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 .. t...@fries.net |\ 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:freedae...@ekiga.net | ..in support of free software solutions. \ sip:4052279...@ekiga.net \ 37E7 D3EB 74D0 8D66 A68D B866 0326 204E 3F42 004A http://todd.fries.net/pgp.txt
Re: IPSec VPNs when traffic originates from a daemon on the OBSD firewall
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.
IPSec VPNs when traffic originates from a daemon on the OBSD firewall
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
Re: IPSec VPNs when traffic originates from a daemon on the OBSD firewall
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.
Re: IPSec VPNs when traffic originates from a daemon on the OBSD firewall
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.
Re: IPSec VPNs when traffic originates from a daemon on the OBSD firewall
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
Re: IPSec VPNs when traffic originates from a daemon on the OBSD firewall
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
Re: IPSec VPNs when traffic originates from a daemon on the OBSD firewall
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.
Re: IPSec VPNs when traffic originates from a daemon on the OBSD firewall
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.
Re: IPSec VPNs when traffic originates from a daemon on the OBSD firewall
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.
Re: IPSec VPNs when traffic originates from a daemon on the OBSD firewall
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 a...@brandwatch.com 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.
