ipsec routing problem
Hi everyone, I have a box (SuSE 9.1) with 3 network-cards (eth0 for internal, eth1 for dmz, eth2 for internet), that is to be client to a ipsec-vpn. But when I try to connect to the vpn-server (217.0.1.1) I get the following errors: Oct 7 11:28:29 vpn_clnt pluto[21240]: "VPN_Server": route-client output: RTNETLINK answers: Network is unreachable Oct 7 11:28:29 vpn_clnt pluto[21240]: "VPN_Server": route-client output: /usr/lib/ipsec/_updown: `ip route add 192.168.0.0/24 via 217.0.1.1 dev eth2' failed Oct 7 11:28:29 vpn_clnt pluto[21240]: "VPN_Server": route-client command exited with status 2 Oct 7 11:28:29 vpn_clnt ipsec__plutorun: 003 "VPN_Server": route-client command exited with status 2 Oct 7 11:28:29 vpn_clnt ipsec__plutorun: 025 "VPN_Server": could not route Oct 7 11:28:29 vpn_clnt ipsec__plutorun: ...could not route conn "VPN_Server" Oct 7 11:28:29 vpn_clnt pluto[21240]: "VPN_Server" #1: initiating Main Mode Oct 7 11:28:29 vpn_clnt ipsec__plutorun: 104 "VPN_Server" #1: STATE_MAIN_I1: initiate Oct 7 11:28:29 vpn_clnt ipsec__plutorun: ...could not start conn "VPN_Server" Oct 7 11:28:29 vpn_clnt pluto[21240]: "VPN_Server" #1: Informational Exchange message must be encrypted The network is reachable for sure, as I connect to the box remote and as the isakmp-packeges get to the vpn-server and the other way around. ipsec.conf looks like this: config setup interfaces="ipsec0=eth2" # Debug-logging controls: "none" for (almost) none, "all" for lots. #klipsdebug=all #plutodebug=all # Certificate Revocation List handling #crlcheckinterval=600 #strictcrlpolicy=yes # Change rp_filter setting, default = 0 (switch off) #rp_filter=%unchanged # Switch on NAT-Traversal (if patch is installed) #nat_traversal=yes # default settings for connections conn %default # Default: %forever (try forever) #keyingtries=3 # Sig keys (default: %dnsondemand) leftrsasigkey=%cert rightrsasigkey=%cert # Lifetimes, defaults are 1h/8hrs #ikelifetime=20m #keylife=1h #rekeymargin=8m # OE policy groups are disabled by default conn block auto=ignore conn clear auto=ignore conn private auto=ignore conn private-or-clear auto=ignore conn clear-or-private auto=ignore conn packetdefault auto=ignore #conn OEself # auto=ignore # Add connections here. conn VPN_Server left=217.0.0.49 leftcert=clientCert.pem leftsubnet=10.0.0.0/24 right=217.0.1.1 rightcert=serverCert.pem rightsubnet=192.168.0.0/24 auto=start Might one reason for the problem be the overlapping interfaces for eth1 and eth2 (eth1 has 217.0.0.51/255.255.255.248, eth2 has 217.0.0.49/255.255.255.0 but actually is only connected via direct link to .50, static routes for machines in the dmz are set via eth1)? The network is reachable for sure, as I connect to the box remote and as the isakmp-packeges get to the vpn-server and the other way around. Thanks and greetings, Ralf
add leftnexthop and rightnexthop even if they are the default gateway. On Thu, 7 Oct 2004, Ralf Ronneburger wrote:
Hi everyone,
I have a box (SuSE 9.1) with 3 network-cards (eth0 for internal, eth1 for dmz, eth2 for internet), that is to be client to a ipsec-vpn. But when I try to connect to the vpn-server (217.0.1.1) I get the following errors:
Oct 7 11:28:29 vpn_clnt pluto[21240]: "VPN_Server": route-client output: RTNETLINK answers: Network is unreachable Oct 7 11:28:29 vpn_clnt pluto[21240]: "VPN_Server": route-client output: /usr/lib/ipsec/_updown: `ip route add 192.168.0.0/24 via 217.0.1.1 dev eth2' failed Oct 7 11:28:29 vpn_clnt pluto[21240]: "VPN_Server": route-client command exited with status 2 Oct 7 11:28:29 vpn_clnt ipsec__plutorun: 003 "VPN_Server": route-client command exited with status 2 Oct 7 11:28:29 vpn_clnt ipsec__plutorun: 025 "VPN_Server": could not route Oct 7 11:28:29 vpn_clnt ipsec__plutorun: ...could not route conn "VPN_Server" Oct 7 11:28:29 vpn_clnt pluto[21240]: "VPN_Server" #1: initiating Main Mode Oct 7 11:28:29 vpn_clnt ipsec__plutorun: 104 "VPN_Server" #1: STATE_MAIN_I1: initiate Oct 7 11:28:29 vpn_clnt ipsec__plutorun: ...could not start conn "VPN_Server" Oct 7 11:28:29 vpn_clnt pluto[21240]: "VPN_Server" #1: Informational Exchange message must be encrypted
The network is reachable for sure, as I connect to the box remote and as the isakmp-packeges get to the vpn-server and the other way around. ipsec.conf looks like this:
config setup interfaces="ipsec0=eth2" # Debug-logging controls: "none" for (almost) none, "all" for lots. #klipsdebug=all #plutodebug=all # Certificate Revocation List handling #crlcheckinterval=600 #strictcrlpolicy=yes # Change rp_filter setting, default = 0 (switch off) #rp_filter=%unchanged # Switch on NAT-Traversal (if patch is installed) #nat_traversal=yes
# default settings for connections conn %default # Default: %forever (try forever) #keyingtries=3 # Sig keys (default: %dnsondemand) leftrsasigkey=%cert rightrsasigkey=%cert # Lifetimes, defaults are 1h/8hrs #ikelifetime=20m #keylife=1h #rekeymargin=8m
# OE policy groups are disabled by default conn block auto=ignore
conn clear auto=ignore
conn private auto=ignore
conn private-or-clear auto=ignore
conn clear-or-private auto=ignore
conn packetdefault auto=ignore
#conn OEself # auto=ignore
# Add connections here. conn VPN_Server left=217.0.0.49 leftcert=clientCert.pem leftsubnet=10.0.0.0/24 right=217.0.1.1 rightcert=serverCert.pem rightsubnet=192.168.0.0/24 auto=start
Might one reason for the problem be the overlapping interfaces for eth1 and eth2 (eth1 has 217.0.0.51/255.255.255.248, eth2 has 217.0.0.49/255.255.255.0 but actually is only connected via direct link to .50, static routes for machines in the dmz are set via eth1)? The network is reachable for sure, as I connect to the box remote and as the isakmp-packeges get to the vpn-server and the other way around.
Thanks and greetings,
Ralf
-- BINGO: rapid deployment look and feel --- Engelbert Gruber -------+ SSG Fintl,Gruber,Lassnig / A6170 Zirl Innweg 5b / Tel. ++43-5238-93535 ---+
Hi Engelbert, engelbert.gruber@ssg.co.at wrote:
add leftnexthop and rightnexthop even if they are the default gateway.
thanks, this helped, although I don't understand why it's needed (as both IPs are public and I never had to use left/rightnexthop before on any connection). But I still get an error, that the connection can't be started (line 4): Oct 7 15:45:43 vpn_clnt pluto[23040]: loading secrets from "/etc/ipsec.secrets" Oct 7 15:45:43 vpn_clnt pluto[23040]: "VPN_Server" #1: initiating Main Mode Oct 7 15:45:43 vpn_clnt ipsec__plutorun: 104 "VPN_Server" #1: STATE_MAIN_I1: initiate Oct 7 15:45:43 vpn_clnt ipsec__plutorun: ...could not start conn "VPN_Server" Oct 7 15:45:44 vpn_clnt pluto[23040]: "VPN_Server" #1: Peer ID is ID_IPV4_ADDR: '217.0.1.1' Oct 7 15:45:44 vpn_clnt pluto[23040]: "VPN_Server" #1: ISAKMP SA established Oct 7 15:45:44 vpn_clnt pluto[23040]: "VPN_Server" #2: initiating Quick Mode PSK+ENCRYPT+TUNNEL+PFS+UP {using isakmp#1} Oct 7 15:45:44 vpn_clnt pluto[23040]: "VPN_Server" #2: sent QI2, IPsec SA established {ESP=>0x8c4050ec <0x7f0b7342} Oct 7 15:45:50 vpn_clnt pluto[23040]: "VPN_Server" #3: we require PFS but Quick I1 SA specifies no GROUP_DESCRIPTION Oct 7 15:45:50 vpn_clnt pluto[23040]: "VPN_Server" #3: sending encrypted notification NO_PROPOSAL_CHOSEN to 217.0.1.1:500 Any ideas about that? Greetings, Ralf
On Thu, 7 Oct 2004, Ralf Ronneburger wrote:
Hi everyone,
I have a box (SuSE 9.1) with 3 network-cards (eth0 for internal, eth1 for dmz, eth2 for internet), that is to be client to a ipsec-vpn. But when I try to connect to the vpn-server (217.0.1.1) I get the following errors:
Oct 7 11:28:29 vpn_clnt pluto[21240]: "VPN_Server": route-client output: RTNETLINK answers: Network is unreachable Oct 7 11:28:29 vpn_clnt pluto[21240]: "VPN_Server": route-client output: /usr/lib/ipsec/_updown: `ip route add 192.168.0.0/24 via 217.0.1.1 dev eth2' failed Oct 7 11:28:29 vpn_clnt pluto[21240]: "VPN_Server": route-client command exited with status 2 Oct 7 11:28:29 vpn_clnt ipsec__plutorun: 003 "VPN_Server": route-client command exited with status 2 Oct 7 11:28:29 vpn_clnt ipsec__plutorun: 025 "VPN_Server": could not route Oct 7 11:28:29 vpn_clnt ipsec__plutorun: ...could not route conn "VPN_Server" Oct 7 11:28:29 vpn_clnt pluto[21240]: "VPN_Server" #1: initiating Main Mode Oct 7 11:28:29 vpn_clnt ipsec__plutorun: 104 "VPN_Server" #1: STATE_MAIN_I1: initiate Oct 7 11:28:29 vpn_clnt ipsec__plutorun: ...could not start conn "VPN_Server" Oct 7 11:28:29 vpn_clnt pluto[21240]: "VPN_Server" #1: Informational Exchange message must be encrypted
The network is reachable for sure, as I connect to the box remote and as the isakmp-packeges get to the vpn-server and the other way around. ipsec.conf looks like this:
config setup interfaces="ipsec0=eth2" # Debug-logging controls: "none" for (almost) none, "all" for lots. #klipsdebug=all #plutodebug=all # Certificate Revocation List handling #crlcheckinterval=600 #strictcrlpolicy=yes # Change rp_filter setting, default = 0 (switch off) #rp_filter=%unchanged # Switch on NAT-Traversal (if patch is installed) #nat_traversal=yes
# default settings for connections conn %default # Default: %forever (try forever) #keyingtries=3 # Sig keys (default: %dnsondemand) leftrsasigkey=%cert rightrsasigkey=%cert # Lifetimes, defaults are 1h/8hrs #ikelifetime=20m #keylife=1h #rekeymargin=8m
# OE policy groups are disabled by default conn block auto=ignore
conn clear auto=ignore
conn private auto=ignore
conn private-or-clear auto=ignore
conn clear-or-private auto=ignore
conn packetdefault auto=ignore
#conn OEself # auto=ignore
# Add connections here. conn VPN_Server left=217.0.0.49 leftcert=clientCert.pem leftsubnet=10.0.0.0/24 right=217.0.1.1 rightcert=serverCert.pem rightsubnet=192.168.0.0/24 auto=start
Might one reason for the problem be the overlapping interfaces for eth1 and eth2 (eth1 has 217.0.0.51/255.255.255.248, eth2 has 217.0.0.49/255.255.255.0 but actually is only connected via direct link to .50, static routes for machines in the dmz are set via eth1)? The network is reachable for sure, as I connect to the box remote and as the isakmp-packeges get to the vpn-server and the other way around.
Thanks and greetings,
Ralf
Hi everyone, now it's almost working (after changing the connection to be added only and starting it manually). Everything seems O.K., no more errors, a route to the private LAN on the other side gets set up via external interface, but when I ping an address in that LAN, then it's routed over the internet and naturally some router tells me "destination host unreachable". As I've read there is no interface ipsec0 in 2.6 any more - is there a way to find out, if a connection is up or not? Besides that - are there any good alternatives to freeswan? In my opinion the configuration and the log-entries of freeswan are infeasable (like: "...could not start conn "VPN_Server" " without giving any reasons even in the highest debug-level). Greetings, Ralf Ralf Ronneburger wrote:
Hi Engelbert,
engelbert.gruber@ssg.co.at wrote:
add leftnexthop and rightnexthop even if they are the default gateway.
thanks, this helped, although I don't understand why it's needed (as both IPs are public and I never had to use left/rightnexthop before on any connection). But I still get an error, that the connection can't be started (line 4):
Oct 7 15:45:43 vpn_clnt pluto[23040]: loading secrets from "/etc/ipsec.secrets" Oct 7 15:45:43 vpn_clnt pluto[23040]: "VPN_Server" #1: initiating Main Mode Oct 7 15:45:43 vpn_clnt ipsec__plutorun: 104 "VPN_Server" #1: STATE_MAIN_I1: initiate Oct 7 15:45:43 vpn_clnt ipsec__plutorun: ...could not start conn "VPN_Server" Oct 7 15:45:44 vpn_clnt pluto[23040]: "VPN_Server" #1: Peer ID is ID_IPV4_ADDR: '217.0.1.1' Oct 7 15:45:44 vpn_clnt pluto[23040]: "VPN_Server" #1: ISAKMP SA established Oct 7 15:45:44 vpn_clnt pluto[23040]: "VPN_Server" #2: initiating Quick Mode PSK+ENCRYPT+TUNNEL+PFS+UP {using isakmp#1} Oct 7 15:45:44 vpn_clnt pluto[23040]: "VPN_Server" #2: sent QI2, IPsec SA established {ESP=>0x8c4050ec <0x7f0b7342} Oct 7 15:45:50 vpn_clnt pluto[23040]: "VPN_Server" #3: we require PFS but Quick I1 SA specifies no GROUP_DESCRIPTION Oct 7 15:45:50 vpn_clnt pluto[23040]: "VPN_Server" #3: sending encrypted notification NO_PROPOSAL_CHOSEN to 217.0.1.1:500
Any ideas about that?
Greetings,
Ralf
participants (2)
-
engelbert.gruber@ssg.co.at
-
Ralf Ronneburger