Hi all, after a half day searching for an error, sniffing and upgrading to the newest shorewall version I give up and the problem to you. I have following configuration in my /etc/shorewall/masq: #INTERFACE SOURCE ADDRESS vlan7::10.231.0.0/16 192.168.222.0/24 10.231.113.30 vlan7 192.168.222.0/24 10.1.0.38 Towards a special network I need a masking of all outgoing traffic to 10.231.113.30, in all other cases I use the basic address of the interface for masking. What happens? Nothing - no packet towards an address in 10.231.0.0 leaves the interface. If I swap the entries in the config file, the packets go through the interface, but are masked with the wrong IP (what would be the expected behavior). So I''m sure that there is no fault in the other config files. 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? Thanks, Christian ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Christian Vieser wrote:> Hi all, > > after a half day searching for an error, sniffing and upgrading to the > newest shorewall version I give up and the problem to you. I have > following configuration in my /etc/shorewall/masq: > > #INTERFACE SOURCE ADDRESS > vlan7::10.231.0.0/16 192.168.222.0/24 10.231.113.30 > vlan7 192.168.222.0/24 10.1.0.38 > > Towards a special network I need a masking of all outgoing traffic to > 10.231.113.30, in all other cases I use the basic address of the > interface for masking. What happens? Nothing - no packet towards an > address in 10.231.0.0 leaves the interface. If I swap the entries in the > config file, the packets go through the interface, but are masked with > the wrong IP (what would be the expected behavior). So I''m sure that > there is no fault in the other config files. > > 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?Please forward the information requested at http://www.shorewall.net/support.htm#Guidelines (case 3). We need it in order to see what Netfilter rules are being generated. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Hi all,
after a half day searching for an error, sniffing and upgrading to the
newest shorewall version I give up and the problem to you. I have
following configuration in my /etc/shorewall/masq:
#INTERFACE SOURCE ADDRESS
vlan7::10.231.0.0/16 192.168.222.0/24 10.231.113.30
vlan7 192.168.222.0/24 10.1.0.38
Towards a special network I need a masking of all outgoing traffic to
10.231.113.30, in all other cases I use the basic address of the
interface for masking. What happens? Nothing - no packet towards an
address in 10.231.0.0 leaves the interface. If I swap the entries in the
config file, the packets go through the interface, but are masked with
the wrong IP (what would be the expected behavior). So I''m sure that
there is no fault in the other config files.
Netfilter also seems to has the correct rules (whole dump enclosed):
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?
Thanks,
Christian
-------------------------------------------------------------------------
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
Christian Vieser wrote:> Hi all, > > after a half day searching for an error, sniffing and upgrading to the > newest shorewall version I give up and the problem to you. I have > following configuration in my /etc/shorewall/masq: > > #INTERFACE SOURCE ADDRESS > vlan7::10.231.0.0/16 192.168.222.0/24 10.231.113.30 > vlan7 192.168.222.0/24 10.1.0.38 > > Towards a special network I need a masking of all outgoing traffic to > 10.231.113.30, in all other cases I use the basic address of the > interface for masking. What happens? Nothing - no packet towards an > address in 10.231.0.0 leaves the interface. If I swap the entries in the > config file, the packets go through the interface, but are masked with > the wrong IP (what would be the expected behavior). So I''m sure that > there is no fault in the other config files. > > Netfilter also seems to has the correct rules (whole dump enclosed): > > 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. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- 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
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 \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- 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
Tom Eastep wrote:> Christian Vieser wrote: >> Hi all, >> >> after a half day searching for an error, sniffing and upgrading to the >> newest shorewall version I give up and the problem to you. I have >> following configuration in my /etc/shorewall/masq: >> >> #INTERFACE SOURCE ADDRESS >> vlan7::10.231.0.0/16 192.168.222.0/24 10.231.113.30 >> vlan7 192.168.222.0/24 10.1.0.38 >> >> Towards a special network I need a masking of all outgoing traffic to >> 10.231.113.30, in all other cases I use the basic address of the >> interface for masking. What happens? Nothing - no packet towards an >> address in 10.231.0.0 leaves the interface. If I swap the entries in the >> config file, the packets go through the interface, but are masked with >> the wrong IP (what would be the expected behavior). So I''m sure that >> there is no fault in the other config files. >> >> Netfilter also seems to has the correct rules (whole dump enclosed): >> >> 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,Of course I meant "...when the SOURCE IP address is rewritten..." -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- 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
Tom Eastep wrote:> > 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. > > -Tom >Thank you Tom!!! That was the right guess. "setkey -F -P" and now the packets go through. The typical hassle with old configs remaining somewhere in the system. Thanks a lot, Christian -- Christian Vieser Tel: +49 (0) 7251.93258-124 Fax: +49 (0) 7251.93258-119 E-Mail: vieser@opti-serv.de ------------------------------------------------- opti-serv Unternehmensberatung für Servicemanagement GmbH Geschäftsführer Klaus Graf Moltkestr. 13 76689 Karlsdorf-Neuthard Amtsgericht Mannheim HRB Nr. 701508 Tel: +49 (0) 7251.366753 Fax: +49 (0) 7251.349493 E-Mail: info@opti-serv.de Web: www.opti-serv.de ------------------------------------------------------------------------- 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