Hi, 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:03.196443 IP 10.254.1.1 > 10.254.1.2: OSPFv2, Database Description, length 32 19:21:06.220716 IP 10.254.1.1 > 10.254.1.2: OSPFv2, LS-Request, length 60 19:21:06.224716 IP 10.254.1.2 > 10.254.1.1: OSPFv2, LS-Update, length 156 19:21:06.224716 IP 10.254.1.2 > 224.0.0.5: OSPFv2, Hello, length 48 19:21:06.228717 IP 10.254.1.1 > 224.0.0.5: OSPFv2, LS-Update, length 56 19:21:06.228717 IP 10.254.1.1 > 224.0.0.5: OSPFv2, LS-Update, length 56 19:21:06.232717 IP 10.254.1.2 > 10.254.1.1: OSPFv2, LS-Request, length 552 19:21:06.232717 IP 10.254.1.2 > 10.254.1.1: OSPFv2, LS-Request, length 552 19:21:06.248718 IP 10.254.1.1 > 10.254.1.2: OSPFv2, LS-Update, length 1312 19:21:06.268720 IP 10.254.1.1 > 10.254.1.2: OSPFv2, LS-Update, length 1312 19:21:06.276721 IP 10.254.1.2 > 10.254.1.1: OSPFv2, LS-Ack, length 904 19:21:07.276811 IP 10.254.1.2 > 224.0.0.5: OSPFv2, LS-Update, length 112 19:21:07.276811 IP 10.254.1.2 > 10.254.1.1: OSPFv2, LS-Ack, length 944 19:21:07.276811 IP 10.254.1.1 > 224.0.0.5: OSPFv2, LS-Update, length 112 19:21:07.336816 IP 10.254.1.1 > 224.0.0.5: OSPFv2, Hello, length 48 19:21:08.352908 IP 10.254.1.1 > 10.254.1.2: OSPFv2, LS-Ack, length 44 19:21:11.209165 IP 10.254.1.1 > 10.254.1.2: OSPFv2, LS-Update, length 112 19:21:11.213166 IP 10.254.1.2 > 10.254.1.1: OSPFv2, LS-Ack, length 44 19:21:12.213256 IP 10.254.1.2 > 10.254.1.1: OSPFv2, LS-Update, length 112 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. Did I miss something obvious ? ------------------------------------------------------------------------------ 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/
On 08/21/2012 10:21 AM, Laurent CARON wrote:> Hi, > > 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.1Can we see the output of ''shorewall dump'' with Shorewall started please? -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/
On 21/08/2012 20:53, Tom Eastep wrote:> Can we see the output of ''shorewall dump'' with Shorewall started please?Sending it privately to you since the file contains public addressing. ------------------------------------------------------------------------------ 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/
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/
On Fri, Aug 24, 2012 at 06:42:59AM -0700, Tom Eastep wrote:> 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.I''d like to thank you Tom for his great help while debugging this strange issue I''ve been facing. Laurent ------------------------------------------------------------------------------ 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/