[Openswan Users] IPSec auto up error

Vuppula, Srinivas srinivas.vuppula at intel.com
Wed Oct 31 16:43:49 EDT 2007


Still fails as below.
 
sh-3.1# ebtables -t filter -I INPUT -p 0x0800 -ip-proto 50 -j ACCEPT
Bad argument : '50'.
sh-3.1# ebtables -t filter -I INPUT -p 0x0800 -ip-proto 17 --ip-dport
500 -j ACC
EPT
Bad argument : '17'.

________________________________

From: Peter McGill [mailto:petermcgill at goco.net] 
Sent: Wednesday, October 31, 2007 1:40 PM
To: Vuppula, Srinivas
Subject: RE: [Openswan Users] IPSec auto up error


Correct reading a bit more of the man page for ebtables, explains that
it works at the ethernet level
not at the ip level so what you need is actually...
ebtables -t filter -I INPUT -p 0x0800 -ip-proto 50 -j ACCEPT # ESP 
ebtables -t filter -I INPUT -p 0x0800 -ip-proto 17 --ip-dport 500 -j
ACCEPT # ISAKMP
See http://ebtables.sourceforge.net/ebtables-man.html for more details.
Note what I said before about OUTPUT chain still applies.
 
Peter McGill
 



________________________________

	From: Vuppula, Srinivas [mailto:srinivas.vuppula at intel.com] 
	Sent: October 31, 2007 4:21 PM
	To: petermcgill at goco.net
	Subject: RE: [Openswan Users] IPSec auto up error
	
	
	well i had tried that and some other combinations but it seems
not 
	sh-3.1# ebtables -t filter -I INPUT -p 50 -j ACCEPT
	Sorry, protocols have values above or equal to 0x0600.

________________________________

	From: Peter McGill [mailto:petermcgill at goco.net] 
	Sent: Wednesday, October 31, 2007 12:56 PM
	To: Vuppula, Srinivas
	Subject: RE: [Openswan Users] IPSec auto up error
	
	
	I've never heard of it, however a quick internet search to find
the website and the manual describes it as an enhanced version of
iptables.
	Although it looks less like an enhancement than an alternative,
it looks like the commands will need minimal changes.
	However the traffic you need to allow is all traffic to and from
protocol 50 (esp), note that's protocol 50 not port 50.
	You also need to allow all traffic to and from udp (protocol 17)
on port 500 (isakmp).
	Looks like the following will do the trick.
	
	ebtables -t filter -I INPUT -p 50 -j ACCEPT # ESP
	ebtables -t filter -I INPUT -p 17 --ip-dport 500 -j ACCEPT #
ISAKMP
	You may also need to repeat those two lines substituting INPUT
for OUTPUT if it still doesn't work.
	 
	Peter McGill
	 


________________________________

		From: Vuppula, Srinivas
[mailto:srinivas.vuppula at intel.com] 
		Sent: October 31, 2007 2:46 PM
		To: petermcgill at goco.net
		Subject: RE: [Openswan Users] IPSec auto up error
		
		
		This system seems to use ebtables instead. Do you know
the equivalent command to use with ebtables?

________________________________

		From: Peter McGill [mailto:petermcgill at goco.net] 
		Sent: Wednesday, October 31, 2007 6:33 AM
		To: Vuppula, Srinivas
		Subject: RE: [Openswan Users] IPSec auto up error
		
		
		Yes I think that is the cause, since your error is an
ICMP unreachable from your laptop computer,
		that leads me to suspect that your laptop may be
rejecting the IPSec packets, causing that error.
		Normally you'd fix that with iptables, but your system
seems unable to do that.
		It also seems that perl is also missing some files, and
that is why you cannot run ipsec verify.
		It will be difficult to fix your system without first
installing a more complete system on it, if possible.
		At the very least you'll need to be able to alter the
firewall rules. Is there some other way that the
		embedded system gives you to alter the firewall rules?
You could use that to allow the ipsec traffic.
		 
		Peter McGill
		 
		
		

________________________________

			From: Vuppula, Srinivas
[mailto:srinivas.vuppula at intel.com] 
			Sent: October 30, 2007 8:34 PM
			To: petermcgill at goco.net
			Subject: RE: [Openswan Users] IPSec auto up
error
			
			
			I got both static on either side.
			Here is what you asked.
			 
			Left system (laptop)
			    sh-3.1# route -n
			Kernel IP routing table
			Destination     Gateway         Genmask
Flags Metric Ref    Use Iface
			10.8.0.0        0.0.0.0         255.255.255.0
U     0      0        0 br0
			192.168.1.0     0.0.0.0         255.255.255.0
U     0      0        0 eth0
			192.168.10.0    0.0.0.0         255.255.255.0
U     0      0        0 br0
			169.254.0.0     0.0.0.0         255.255.0.0
U     0      0        0 eth0
			0.0.0.0         192.168.1.1     0.0.0.0
UG    0      0        0 eth0
			 
			 
			sh-3.1# ifconfig
			br0       Link encap:Ethernet  HWaddr
00:15:05:15:05:15
			          inet addr:192.168.10.20
Bcast:192.168.10.255  Mask:255.255.255.0
			          inet6 addr: fe80::215:5ff:fe15:515/64
Scope:Link
			          UP BROADCAST RUNNING MULTICAST
MTU:1500  Metric:1
			          RX packets:121 errors:0 dropped:0
overruns:0 frame:0
			          TX packets:12 errors:0 dropped:0
overruns:0 carrier:0
			          collisions:0 txqueuelen:0
			          RX bytes:7496 (7.3 KiB)  TX bytes:936
(936.0 b)
			 
			br0:1     Link encap:Ethernet  HWaddr
00:15:05:15:05:15
			          inet addr:10.8.0.2  Bcast:10.8.0.255
Mask:255.255.255.0
			          UP BROADCAST RUNNING MULTICAST
MTU:1500  Metric:1
			 
			eth0      Link encap:Ethernet  HWaddr
00:1C:05:C0:5C:05
			          inet addr:192.168.1.102
Bcast:192.168.1.255  Mask:255.255.255.0
			          inet6 addr: fe80::21c:5ff:fec0:5c05/64
Scope:Link
			          UP BROADCAST RUNNING MULTICAST
MTU:1500  Metric:1
			          RX packets:256 errors:0 dropped:0
overruns:0 frame:0
			          TX packets:134 errors:0 dropped:0
overruns:0 carrier:0
			          collisions:0 txqueuelen:100
			          RX bytes:22956 (22.4 KiB)  TX
bytes:12352 (12.0 KiB)
			          Base address:0xdc00
Memory:ffa40000-ffa60000
			 
			eth1      Link encap:Ethernet  HWaddr
00:15:05:15:05:15
			          inet6 addr: fe80::215:5ff:fe15:515/64
Scope:Link
			          UP BROADCAST RUNNING MULTICAST
MTU:1500  Metric:1
			          RX packets:72 errors:0 dropped:0
overruns:0 frame:0
			          TX packets:238 errors:0 dropped:0
overruns:0 carrier:0
			          collisions:0 txqueuelen:1000
			          RX bytes:6708 (6.5 KiB)  TX
bytes:18992 (18.5 KiB)
			 
			lo        Link encap:Local Loopback
			          inet addr:127.0.0.1  Mask:255.0.0.0
			          inet6 addr: ::1/128 Scope:Host
			          UP LOOPBACK RUNNING  MTU:16436
Metric:1
			          RX packets:13 errors:0 dropped:0
overruns:0 frame:0
			          TX packets:13 errors:0 dropped:0
overruns:0 carrier:0
			          collisions:0 txqueuelen:0
			          RX bytes:2812 (2.7 KiB)  TX bytes:2812
(2.7 KiB)
			 
			 
			Right System--This seems to be alright..It has
been working between another linux system
			Attached file has the info.
			 
			I tried with all mentioned below. My laptop
seems to be having problem running iptables command to accept tcp and
udp.
			 
			sh-3.1# iptables -I INPUT -p 50 -j ACCEPT
			iptables v1.3.7: Couldn't load target
`standard':/builddir/build/BUILD/xen-sv-al
	
pha-15294/tmp-dist-sv/sosrd/lib/iptables/libipt_standard.so: cannot open
shared
			object file: No such file or directory
			 
			Try `iptables -h' or 'iptables --help' for more
information.
			 
			I guess its all because of this command failure
that i do not get the connection up. I do see libipt_standard.so in lib
folder, but not at the path it compalined above. Do you think being not
able to execute iptables command is the cause of all.
			 
			 
			 
			 
			 
			 
			 
			 
			 
			 
			 
			 
			 
			 
			 
			 
			 
			
			Show us your ifconfig and route -n outputs for
both hosts.
			How does the 192.168.1.102 address/host fit in,
is it the "road warrior" or gateway?
			 
			Openswan doesn't really care how the host get's
it's IP address, so long as...
			a) The IP address is available before the
Openswan pluto daemon is started and
			b) If the IP address is changed the Openswan
pluto daemon is immediately restarted.
			 
			It does however matter when writing your conf.
			If you have static addresses then put them in
left and right.
			If you have a dynamic address on one end then in
it's ipsec.conf put left=%defaultroute,
			and in the other ipsec.conf put right=%any to
handle the unknown/changing address.
			In this case you also must start the connection
from the side with the dynamic address.
			This is true anytime you write your conf files
this way even if both sides have static IPs,
			if for example your using a dynamic IP
configuration but testing it with a static IP.
			 
			When Openswan documentation and the people on
this list talk about road warrior, we mean
			one side of the tunnel has a dynamic IP, if you
have static IP's then it's a normal tunnel not road warrior.
			(Althouth the configs are identical except for
the above mentions of left=%defaultroute and right=%any.)
			 
			Peter McGill

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20071031/67233987/attachment-0001.html 


More information about the Users mailing list