Re: Source Interface for outgoing connections
2007/2/26, Darren Spruell [EMAIL PROTECTED]: On 2/26/07, Samuel Moqux [EMAIL PROTECTED] wrote: I'm having some issues with an ipsec connection with vpnc (isakmp is not an option, since does not support xauth, and I don't control the other end) from an OpenBSD firewall/router to a Cisco device. I think problems could be natt related so I would like to eliminate nat from the equation, but the problem is that the outside interface is a private address. This firewall routes between a DMZ (public /29), a LAN segment (private /24), and the outside (private /30). -- LAN --- OpenBSD -- 10.90.0.0/30 --- Outside Router -- INET | | DMZ (public /29) Right now, I need to NAT on the Outside Router, since internet routed packets from the OpenBSD box go out with a private address. What I would like to achieve is that packets destined to internet get sourced with DMZ's interface, which is internet routable, and without pf tricks(I don't want NAT, remember). If you could get vpnc to bind to a specific interface it seems like that would be possible. Can you see if that's an option? No it isn't. Looking at the source does not seem hard to do, however. Maybe I'll make an small patch to address this. It's not an uncommon situation to sit a public addressable range in a DMZ, and use a reserved one for routing I think. The way I see it, NAT may not be an issue; any worthwhile modern IPsec implementation supports NAT traversal, which vpnc appears to (I see a reference to '--natt-mode' on their page.) If you can support NAT-T on the client and server, it may be a non-issue for you. Yes, I have tried with different natt modes. But connection dies 2h50min after. I'm not sure if the problem is natt related, it's just to discard options and simplify the configuration. Haven't used vpnc myself, but just looking at the package install message there's a couple of considerations: I had done that. Thanks for your comments, Darren
Source Interface for outgoing connections
Hi everyone, I'm having some issues with an ipsec connection with vpnc (isakmp is not an option, since does not support xauth, and I don't control the other end) from an OpenBSD firewall/router to a Cisco device. I think problems could be natt related so I would like to eliminate nat from the equation, but the problem is that the outside interface is a private address. This firewall routes between a DMZ (public /29), a LAN segment (private /24), and the outside (private /30). -- LAN --- OpenBSD -- 10.90.0.0/30 --- Outside Router -- INET | | DMZ (public /29) Right now, I need to NAT on the Outside Router, since internet routed packets from the OpenBSD box go out with a private address. What I would like to achieve is that packets destined to internet get sourced with DMZ's interface, which is internet routable, and without pf tricks(I don't want NAT, remember). Bridging is not an option, since the Outside router needs its own IP for its own purposes. I don't know it its possible. If it's, please, let me know (pointing a man page would be OK). Thanks in advance
Re: Source Interface for outgoing connections
On 2/26/07, Samuel Moqux [EMAIL PROTECTED] wrote: I'm having some issues with an ipsec connection with vpnc (isakmp is not an option, since does not support xauth, and I don't control the other end) from an OpenBSD firewall/router to a Cisco device. I think problems could be natt related so I would like to eliminate nat from the equation, but the problem is that the outside interface is a private address. This firewall routes between a DMZ (public /29), a LAN segment (private /24), and the outside (private /30). -- LAN --- OpenBSD -- 10.90.0.0/30 --- Outside Router -- INET | | DMZ (public /29) Right now, I need to NAT on the Outside Router, since internet routed packets from the OpenBSD box go out with a private address. What I would like to achieve is that packets destined to internet get sourced with DMZ's interface, which is internet routable, and without pf tricks(I don't want NAT, remember). If you could get vpnc to bind to a specific interface it seems like that would be possible. Can you see if that's an option? The way I see it, NAT may not be an issue; any worthwhile modern IPsec implementation supports NAT traversal, which vpnc appears to (I see a reference to '--natt-mode' on their page.) If you can support NAT-T on the client and server, it may be a non-issue for you. Haven't used vpnc myself, but just looking at the package install message there's a couple of considerations: snip --- vpnc-0.3.3p1 --- In order for vpnc to actually get any received IPsec packet, you have to disable ESP in your kernel like this: sysctl net.inet.esp.enable=0 If you are behind a NAT gateway, you have to disable UDP encapsulation as well: sysctl net.inet.esp.udpencap=0 /snip DS
