On 08/21/2012 10:21 AM, Laurent CARON wrote: > I'm having quite a bit of trouble managing to get Shorewall playing nice > (see below) with OSPF over GRE over IPSec tunnels. > > Purpose: > Running OSPF over an IPSec tunnel (thus adding GRE). > > I did set up my ipsec tunnel, the GRE and OSPF bits are all happily > running, ruling out any major mistake in config on this end. > > As soon as I start shorewall I start to see martian packets going > through the GRE tunnel having source address the public IP of the source > system. > > > Here is the setup: > Endpoint A Endpoint B > Info > Version 4.5.5.3-1~bpo60+1 4.5.5.3-1~bpo60+1 > Node Name FRC VTY > Public IP 1.2.3.4 9.8.7.6 > IPSec IP 172.31.254.11 172.31.254.4 > Loopback 172.31.255.11 172.31.255.4 > GRE tunnel 10.254.1.2 10.254.1.1 > > When shorewall is started on endpoint B, a tcpdump on the GRE interface > of A shows: > 19:14:35.045470 IP 10.254.1.1 > 224.0.0.5: OSPFv2, Hello, length 44 > 19:14:37.049650 IP 1.2.3.4 > 9.8.7.6: ESP(spi=0x3f2f8882,seq=0x383), length > 132 > 19:14:45.106376 IP 10.254.1.1 > 224.0.0.5: OSPFv2, Hello, length 44 > 19:14:47.110557 IP 1.2.3.4 > 9.8.7.6: ESP(spi=0x3f2f8882,seq=0x385), length > 132 > > As soon as I stop shorewall on endpoint A, traffic (including OSPF > exchanges) are fine (see below): > 19:21:01.172261 IP 10.254.1.1 > 10.254.1.2: OSPFv2, Database Description, > length 32 > 19:21:03.176441 IP 10.254.1.2 > 10.254.1.1: OSPFv2, Database Description, > length 32 > 19:21:03.184442 IP 10.254.1.1 > 10.254.1.2: OSPFv2, Database Description, > length 1052 > 19:21:03.188443 IP 10.254.1.2 > 10.254.1.1: OSPFv2, Database Description, > length 1052 ... > 19:21:12.313265 IP 10.254.1.1 > 10.254.1.2: OSPFv2, LS-Ack, length 44 > > No more public IPs come in the play.
Laurent and I have been exchanging emails regarding this problem for several days. While the root cause of the issue is not fully understood, I have been able to create a simple Shorewall patch that works around the issue. The patch unconditionally restores the connection mark to the packet mark early in the mangle PREROUTING and OUTPUT chains. Previously, the connection mark was restored only if it was non-zero. Laurent is running a 3.5.0 kernel; it is unknown whether the issue exists when running earlier kernels but I suspect not. The patch will be included in all future Shorewall releases. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
