Tom Eastep wrote: > Christian Vieser wrote: >> >> Chain vlan7_masq (1 references) >> pkts bytes target prot opt in out source >> destination >> 10 600 SNAT 0 -- * * 192.168.222.0/24 >> 10.231.0.0/16 to:10.231.113.30 >> 2 96 SNAT 0 -- * * 192.168.222.0/24 >> 0.0.0.0/0 to:10.1.0.38 >> >> I know that I had the same construction working some month ago. Only >> difference is, that there it was a "real" eth interface and now it's a >> vlan. >> >> Any idea? > > I suspect that with the destination IP address rewritten to 10.231.113.30, > the traffic then matches one of your SPD entries so the kernel is trying to > send it down an IPSEC tunnel.
This would occur if the destination IP address was in 10.231.8/0/24 or was 10.231.100.53. Your report did not indicate which destination IP addresses you were trying to access. Also, because you didn't clear the Netfilter counters and attempt a connection before capturing the dump, the values of the counters don't give us any real help (11GB of data have been forwarded through the firewall since the counters were last reset). But I see that at least some connections (10) have matched the first rule. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ [EMAIL PROTECTED] PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------- SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
