Kevin Miller, Jr.
2003-Nov-04 12:51 UTC
[Shorewall-users] Shorewall and 2.6.0-test9 kernel
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Has anyone got Shorewall to work with the 2.6.0-test9 kernel? If so, I would be curious to see your kernel configs so I can get my firewall working again. - -- Kevin Miller, Jr. Masters of Public Affairs, Comparative and International Affairs, Information Systems, and Nonprofit Management, School of Public and Environmental Affairs Indiana University - Bloomington http://www.amerasianworld.com kevmille@e-civilsociety.org mobile: 812-219-5047 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/p2hRP2TQUAjSykARAub2AJwMcZhZa9zLZspeYpzuQ3c4C29gwACgi/vQ Sae7kto7thzKmU1WtWNhafQ=w80i -----END PGP SIGNATURE-----
I have Shorewall 1.4.7 configured with ProxyARP. All of my IP addresses are part of a public Class C network. Servers on the Internet see all communication as originating from the IP address of my external interface on the firewall. As a result of this behavior I have added an additional PTR record to my DNS so that reverse lookups against my firewall''s IP address will return the hostname of my mailserver. Now I am having a problem with a mailserver that doesn''t want receive email from my system because the hostname of my mailserver doesn''t resolve to the same IP address as it appears to be sent from. Is there a configuration parameter that will change this behavior? If more detailed configuration information is required to answer this question let me know. Steve Ledwith San Jose Web steve@sanjoseweb.com www.sanjoseweb.com 408-226-5155
I think you want to use SNAT: http://www.shorewall.net/shorewall_setup_guide.htm#SNAT -Alex Martin http://www.rettc.com ----- Original Message ----- From: "Steve Ledwith" <sanjoseweb@hotmail.com> To: "Shorewall Users Mailing List" <shorewall-users@lists.shorewall.net> Sent: Tuesday, November 04, 2003 3:14 PM Subject: [Shorewall-users] ProxyARP question> I have Shorewall 1.4.7 configured with ProxyARP. All of my IP addressesare> part of a public Class C network. Servers on the Internet see all > communication as originating from the IP address of my external interfaceon> the firewall. As a result of this behavior I have added an additional PTR > record to my DNS so that reverse lookups against my firewall''s IP address > will return the hostname of my mailserver. Now I am having a problem witha> mailserver that doesn''t want receive email from my system because the > hostname of my mailserver doesn''t resolve to the same IP address as it > appears to be sent from. Is there a configuration parameter that willchange> this behavior? > > If more detailed configuration information is required to answer this > question let me know. > > > Steve Ledwith > San Jose Web > > steve@sanjoseweb.com > www.sanjoseweb.com > 408-226-5155 > _______________________________________________ > Shorewall-users mailing list > Post: Shorewall-users@lists.shorewall.net > Subscribe/Unsubscribe:https://lists.shorewall.net/mailman/listinfo/shorewall-users> Support: http://www.shorewall.net/support.htm > FAQ: http://www.shorewall.net/FAQ.htm >
> I have Shorewall 1.4.7 configured with ProxyARP. All of my IP addresses > are part of a public Class C network. Servers on the Internet see all > communication as originating from the IP address of my external > interface on the firewall.If that is the case, you are misusing Proxy ARP. Proxy ARP is a trick to get around the lack of proper routing and doesn''t rewrite IP headers in any way. It sounds like you are also doing SNAT on traffic outbound from your servers. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline \ http://www.shorewall.net Washington, USA \ teastep@shorewall.net
If I''m doing SNAT on outbound traffic it''s not intentional. My orginal configuration was based on the 3-interface quick start. I have included some of my configuration files as attachments. Steve Ledwith San Jose Web steve@sanjoseweb.com www.sanjoseweb.com 408-226-5155 ----- Original Message ----- From: "Tom Eastep" <teastep@shorewall.net> To: <shorewall-users@lists.shorewall.net> Sent: Tuesday, November 04, 2003 2:37 PM Subject: Re: [Shorewall-users] ProxyARP question> > > I have Shorewall 1.4.7 configured with ProxyARP. All of my IP addresses > > are part of a public Class C network. Servers on the Internet see all > > communication as originating from the IP address of my external > > interface on the firewall. > > If that is the case, you are misusing Proxy ARP. Proxy ARP is a trick to > get around the lack of proper routing and doesn''t rewrite IP headers in > any way. > > It sounds like you are also doing SNAT on traffic outbound from yourservers.> > -Tom > -- > Tom Eastep \ Nothing is foolproof to a sufficiently talented fool > Shoreline \ http://www.shorewall.net > Washington, USA \ teastep@shorewall.net > > > > _______________________________________________ > Shorewall-users mailing list > Post: Shorewall-users@lists.shorewall.net > Subscribe/Unsubscribe:https://lists.shorewall.net/mailman/listinfo/shorewall-users> Support: http://www.shorewall.net/support.htm > FAQ: http://www.shorewall.net/FAQ.htm >-------------- next part -------------- A non-text attachment was scrubbed... Name: shorewall.conf Type: application/octet-stream Size: 16464 bytes Desc: not available Url : http://lists.shorewall.net/pipermail/shorewall-users/attachments/20031104/0a20beee/shorewall-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: common.def Type: application/octet-stream Size: 1913 bytes Desc: not available Url : http://lists.shorewall.net/pipermail/shorewall-users/attachments/20031104/0a20beee/common-0002.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: hosts Type: application/octet-stream Size: 2458 bytes Desc: not available Url : http://lists.shorewall.net/pipermail/shorewall-users/attachments/20031104/0a20beee/hosts-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: interfaces Type: application/octet-stream Size: 4548 bytes Desc: not available Url : http://lists.shorewall.net/pipermail/shorewall-users/attachments/20031104/0a20beee/interfaces-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: params Type: application/octet-stream Size: 921 bytes Desc: not available Url : http://lists.shorewall.net/pipermail/shorewall-users/attachments/20031104/0a20beee/params-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: policy Type: application/octet-stream Size: 3145 bytes Desc: not available Url : http://lists.shorewall.net/pipermail/shorewall-users/attachments/20031104/0a20beee/policy-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: proxyarp Type: application/octet-stream Size: 11167 bytes Desc: not available Url : http://lists.shorewall.net/pipermail/shorewall-users/attachments/20031104/0a20beee/proxyarp-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: rules Type: application/octet-stream Size: 11259 bytes Desc: not available Url : http://lists.shorewall.net/pipermail/shorewall-users/attachments/20031104/0a20beee/rules-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: common Type: application/octet-stream Size: 112 bytes Desc: not available Url : http://lists.shorewall.net/pipermail/shorewall-users/attachments/20031104/0a20beee/common-0003.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: zones Type: application/octet-stream Size: 406 bytes Desc: not available Url : http://lists.shorewall.net/pipermail/shorewall-users/attachments/20031104/0a20beee/zones-0001.obj
On Tue, 4 Nov 2003, Steve Ledwith wrote:> If I''m doing SNAT on outbound traffic it''s not intentional. My orginal > configuration was based on the 3-interface quick start. > I have included some of my configuration files as attachments. >So it seems that: a) You have multiple public IP addresses (needed for any sane Proxy ARP configuration). b) The link to the three-interface quickstart guide is marked in large red bold font as being for users with only *one* public IP address. c) You used that guide any way. d) Now it is behaving uncorrectly. *The three-interface sample configuration does SNAT on all outbound forwarded traffic*. See your /etc/shorewall/masq file (which you didn''t include in your post). And in your free time, you might take a look at http://www.shorewall.net/shorewall_setup_guide.htm (the Guide for Users that have more than one public IP address). -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
Ok. Whoa. Might need some help here.
After looking at your config files, I must ask some questions:
1) Apparently, you have a whole bunch of networks behind the firewall. Were
you planning on having the firewall (shorewall) route between these
networks, or do you have another router(s) in place already?
2) Is your /etc/shorewall/masq file empty?
3) Have you tried defining your dmz hosts in the "hosts" file all on
one
line? (try this first...)
4) When shorewall is started, what does the routing table look like?
(''ip
route show'')
5) Are you manually configuring this firewall, or possibly are you using
webmin for configuration?
Also, after looking at your complex config, I would suggest reposting ALL
(routes, addressing, etc) of the info as requested on
http://www.shorewall.net/support.htm, so that the gurus may ponder your
situation. I bet I can help figure it out though, just need to understand
what you are trying to do.
Assumuing the previously attached config files is a complete list of your
/etc/shorewall directory, (ie no /etc/shorewall/masq, no /etc/shorewall/nat,
etc) than I would guess that the large list of hosts is getting screwed up
some where (any luck with Q #3?).
I dont see that you are purposely running SNAT anywhere. Since you state
that your firewall is showing all outbound traffic as coming from one ip,
this indicates either funny routing or confused shorewall configuration
(Q#2?)
Knowing the answer to Q#1 would be helpful, for example, does everything
work without the firewall in place?
Last, are you aware of the stale arp cache issues with switching to proxy
arp (http://www.shorewall.net/Documentation.htm#ProxyArp).
And did you read this http://www.tldp.org/HOWTO/Proxy-ARP-Subnet/how.html?
With a better understanding of your setup, I hope to be able to debug this
one.
Doing my best...
-Alex
http://www.rettc.com
----- Original Message -----
From: "Steve Ledwith" <sanjoseweb@hotmail.com>
To: "Shorewall Users Mailing List"
<shorewall-users@lists.shorewall.net>
Sent: Tuesday, November 04, 2003 5:45 PM
Subject: Re: [Shorewall-users] ProxyARP question
> If I''m doing SNAT on outbound traffic it''s not
intentional. My orginal
> configuration was based on the 3-interface quick start.
> I have included some of my configuration files as attachments.
>
>
> Steve Ledwith
> San Jose Web
>
> steve@sanjoseweb.com
> www.sanjoseweb.com
> 408-226-5155
>
> ----- Original Message -----
> From: "Tom Eastep" <teastep@shorewall.net>
> To: <shorewall-users@lists.shorewall.net>
> Sent: Tuesday, November 04, 2003 2:37 PM
> Subject: Re: [Shorewall-users] ProxyARP question
>
>
> >
> > > I have Shorewall 1.4.7 configured with ProxyARP. All of my IP
addresses> > > are part of a public Class C network. Servers on the Internet see
all
> > > communication as originating from the IP address of my external
> > > interface on the firewall.
> >
> > If that is the case, you are misusing Proxy ARP. Proxy ARP is a trick
to
> > get around the lack of proper routing and doesn''t rewrite IP
headers in
> > any way.
> >
> > It sounds like you are also doing SNAT on traffic outbound from your
> servers.
> >
> > -Tom
> > --
> > Tom Eastep \ Nothing is foolproof to a sufficiently talented fool
> > Shoreline \ http://www.shorewall.net
> > Washington, USA \ teastep@shorewall.net
> >
> >
> >
> > _______________________________________________
> > Shorewall-users mailing list
> > Post: Shorewall-users@lists.shorewall.net
> > Subscribe/Unsubscribe:
> https://lists.shorewall.net/mailman/listinfo/shorewall-users
> > Support: http://www.shorewall.net/support.htm
> > FAQ: http://www.shorewall.net/FAQ.htm
> >
>
----------------------------------------------------------------------------
----
> _______________________________________________
> Shorewall-users mailing list
> Post: Shorewall-users@lists.shorewall.net
> Subscribe/Unsubscribe:
https://lists.shorewall.net/mailman/listinfo/shorewall-users> Support: http://www.shorewall.net/support.htm
> FAQ: http://www.shorewall.net/FAQ.htm
After poking around your network, I would venture to guess that you have not subnetted your class c network as your /etc/shorewall/hosts indicates. If I am correct, what (who) made this hosts configuration? -Alex http://www.rettc.com ----- Original Message ----- From: "Steve Ledwith" <sanjoseweb@hotmail.com> To: "Shorewall Users Mailing List" <shorewall-users@lists.shorewall.net> Sent: Tuesday, November 04, 2003 5:45 PM Subject: Re: [Shorewall-users] ProxyARP question> If I''m doing SNAT on outbound traffic it''s not intentional. My orginal > configuration was based on the 3-interface quick start. > I have included some of my configuration files as attachments. > > > Steve Ledwith > San Jose Web > > steve@sanjoseweb.com > www.sanjoseweb.com > 408-226-5155 > > ----- Original Message ----- > From: "Tom Eastep" <teastep@shorewall.net> > To: <shorewall-users@lists.shorewall.net> > Sent: Tuesday, November 04, 2003 2:37 PM > Subject: Re: [Shorewall-users] ProxyARP question > > > > > > > I have Shorewall 1.4.7 configured with ProxyARP. All of my IPaddresses> > > are part of a public Class C network. Servers on the Internet see all > > > communication as originating from the IP address of my external > > > interface on the firewall. > > > > If that is the case, you are misusing Proxy ARP. Proxy ARP is a trick to > > get around the lack of proper routing and doesn''t rewrite IP headers in > > any way. > > > > It sounds like you are also doing SNAT on traffic outbound from your > servers. > > > > -Tom > > -- > > Tom Eastep \ Nothing is foolproof to a sufficiently talented fool > > Shoreline \ http://www.shorewall.net > > Washington, USA \ teastep@shorewall.net > > > > > > > > _______________________________________________ > > Shorewall-users mailing list > > Post: Shorewall-users@lists.shorewall.net > > Subscribe/Unsubscribe: > https://lists.shorewall.net/mailman/listinfo/shorewall-users > > Support: http://www.shorewall.net/support.htm > > FAQ: http://www.shorewall.net/FAQ.htm > > >---------------------------------------------------------------------------- ----> _______________________________________________ > Shorewall-users mailing list > Post: Shorewall-users@lists.shorewall.net > Subscribe/Unsubscribe:https://lists.shorewall.net/mailman/listinfo/shorewall-users> Support: http://www.shorewall.net/support.htm > FAQ: http://www.shorewall.net/FAQ.htm
> -----Original Message----- > From: shorewall-users-bounces@lists.shorewall.net > [mailto:shorewall-users-bounces@lists.shorewall.net] On > Behalf Of Alex Martin > Sent: Tuesday, November 04, 2003 5:56 PM > To: Shorewall Users Mailing List > Subject: Re: [Shorewall-users] ProxyARP question > > > Ok. Whoa. Might need some help here. > > After looking at your config files, I must ask some questions: > > 1) Apparently, you have a whole bunch of networks behind the > firewall. Were > you planning on having the firewall (shorewall) route between these > networks, or do you have another router(s) in place already?Actually I have 2 networks. 209.237.24.0/24 and 209.237.2.128/25.> > 2) Is your /etc/shorewall/masq file empty?It turns out this was the problem. My masq file was not empty. It was from the 3-interface quick start. I removed the masq file And it looks like everything is working fine. Thanks for your help.
--- Steve Ledwith <sanjoseweb@hotmail.com> wrote: As a result of this behavior I have added an additional> PTR > record to my DNS so that reverse lookups against my firewall''s IP > address > will return the hostname of my mailserver. Now I am having a problem > with a > mailserver that doesn''t want receive email from my system because the > hostname of my mailserver doesn''t resolve to the same IP address as > it > appears to be sent from.Pretty straight forward to isolate. What is your mail name in DNS and what does your PTR record look like? What is the actual source ip in the smtp packet after being natted either via DNAT, SNAT or Static NAT? This usually points to acouple of obvious things and that is you didn''t map your in-addr.arpa name correctly on you dns server or Shorewall is misconfigured and packets are leaving shorewalls external interface being masq''ed improperly using an ip other than what you thought. It seems obvious now after reading further that mail is leaving the external interface with an address that doesn''t match with what''s mapped in DNS. Hope you get this straightened out soon. I know how fire and brimestone rain down when CEO''s and Exec''s cant get their mail. :D JBanks __________________________________ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree
On Tue, 4 Nov 2003, Kevin Miller, Jr. wrote:> Has anyone got Shorewall to work with the 2.6.0-test9 kernel? If so, I would > be curious to see your kernel configs so I can get my firewall working again.Yes, I have it (2.6.0-test9-bk1). My config file is in attachment. I would like to ask about related thing. Is here any recommendation or plans how to use Shorewall together with native IPsec in 2.6 kernel? This new kernel code does not create "ipsec" device and so (I think) we cannot use traditional shorewall technique for "ipsec rules". Regards, Milos Wimmer ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Milos Wimmer Internet Services Specialist e-mail: wimmer@zcu.cz Laboratory for Computer Science University of West Bohemia phone : +420 377 632 843 Univerzitni 8, 306 14 Plzen fax : +420 377 421 419 Czech Republic, Europe WWW : http://www.zcu.cz/~wimmer/ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -------------- next part -------------- A non-text attachment was scrubbed... Name: .config.gz Type: application/octet-stream Size: 5727 bytes Desc: .config Url : http://lists.shorewall.net/pipermail/shorewall-users/attachments/20031105/1522a596/config.obj
> > I would like to ask about related thing. Is here any recommendation or > plans how to use Shorewall together with native IPsec in 2.6 kernel? > This new kernel code does not create "ipsec" device and so (I think) we > cannot use traditional shorewall technique for "ipsec rules".I don''t intend to unstall 2.6 until 2.6.0 final is released. At that time, I will start to experiment with 2.6 features and will begin implementing Shorewall support for them. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline \ http://www.shorewall.net Washington, USA \ teastep@shorewall.net
Milos Wimmer wrote:>On Tue, 4 Nov 2003, Kevin Miller, Jr. wrote: > > > >>Has anyone got Shorewall to work with the 2.6.0-test9 kernel? If so, I would >>be curious to see your kernel configs so I can get my firewall working again. >> >> > > Yes, I have it (2.6.0-test9-bk1). My config file is in attachment. > >I would like to ask about related thing. Is here any recommendation or >plans how to use Shorewall together with native IPsec in 2.6 kernel? >This new kernel code does not create "ipsec" device and so (I think) >we cannot use traditional shorewall technique for "ipsec rules". > > Regards, > Milos Wimmer > > > >I''ve been running Shorewall with 2.6 for some time and it works fine. I originally had one problem with module loading in that 2.6 doesn''t seem to automagically load the netfilter modules like 2.4 will. I wound up adding: loadmodule iptable_mangle loadmodule ipt_conntrack loadmodule ipt_state loadmodule ipt_LOG loadmodule ipt_REJECT loadmodule ipt_MASQUERADE loadmodule ipt_TOS loadmodule ipt_TCPMSS to /etc/shorewall/modules so that it would start cleanly. IPSEC is a very good question however. I just setup a tunnel between two systems and with Shorewall cleared, it works. With Shorewall up, it''s giving me truncated-ip problems. It seems that when the packet is decrypted, it gets botched - not sure if it''s hosed on the sender side or receiver - and things just go haywire. I''m not too sure where to look just yet to get this resolved.
Tom Eastep wrote:>>>I would like to ask about related thing. Is here any recommendation or >>> >>> >>plans how to use Shorewall together with native IPsec in 2.6 kernel? >>This new kernel code does not create "ipsec" device and so (I think) we >>cannot use traditional shorewall technique for "ipsec rules". >> >> > >I don''t intend to unstall 2.6 until 2.6.0 final is released. At that time, >I will start to experiment with 2.6 features and will begin implementing >Shorewall support for them. > >-Tom > >In the meantime, any suggestions as to how to resolve this problem with an IPSEC tunnel? The topology is: 192.168.1.0/24 - gw1 (69.22.77.196) - Internet - gw2 (4.63.121.42) - 172.16.100.0/24 12:26:27.844456 4.63.121.42 > 69.22.77.196: ESP(spi=0x00000301,seq=0x67) (DF) [tos 0x10] 12:26:27.844456 truncated-ip - 16 bytes missing! 4.63.121.42 > 69.16.0.60: truncated-ip - 16292 bytes missing! 69.22.77.196 > 69.16.0.60: ip-proto-63 (frag 12804:16336@56992+) [tos 0x34] (ipip-proto-4) 12:26:30.842893 4.63.121.42 > 69.22.77.196: ESP(spi=0x00000301,seq=0x68) (DF) [tos 0x10] 12:26:30.842893 truncated-ip - 16 bytes missing! 4.63.121.42 > 69.16.0.60: truncated-ip - 16292 bytes missing! 69.22.77.196 > 69.16.0.60: ip-proto-63 (frag 12804:16336@56992+) [tos 0x34] (ipip-proto-4) If I drop Shorewall on both ends, IPSEC works fine. With Shorewall up, I get the above. Looking at the packets with Ethereal, the decrypted traffic is totally hosed up. There are IPv3 (yes 3) headers and such and the destination address is obviously dorked up. Any thoughts?
> >> > In the meantime, any suggestions as to how to resolve this problem with > an IPSEC tunnel? The topology is: > > 192.168.1.0/24 - gw1 (69.22.77.196) - Internet - gw2 (4.63.121.42) - > 172.16.100.0/24 > > > 12:26:27.844456 4.63.121.42 > 69.22.77.196: ESP(spi=0x00000301,seq=0x67) > (DF) [tos 0x10] > 12:26:27.844456 truncated-ip - 16 bytes missing! 4.63.121.42 > > 69.16.0.60: truncated-ip - 16292 bytes missing! 69.22.77.196 > > 69.16.0.60: ip-proto-63 (frag 12804:16336@56992+) [tos 0x34] > (ipip-proto-4) 12:26:30.842893 4.63.121.42 > 69.22.77.196: > ESP(spi=0x00000301,seq=0x68) (DF) [tos 0x10] > 12:26:30.842893 truncated-ip - 16 bytes missing! 4.63.121.42 > > 69.16.0.60: truncated-ip - 16292 bytes missing! 69.22.77.196 > > 69.16.0.60: ip-proto-63 (frag 12804:16336@56992+) [tos 0x34] > (ipip-proto-4) > > > If I drop Shorewall on both ends, IPSEC works fine. With Shorewall up, > I get the above. Looking at the packets with Ethereal, the decrypted > traffic is totally hosed up. There are IPv3 (yes 3) headers and such > and the destination address is obviously dorked up. > > Any thoughts? >I suggest the Netfilter list -- Start at www.netfilter.org. This sounds like a kernel networking bug. -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline \ http://www.shorewall.net Washington, USA \ teastep@shorewall.net
Kevin Miller, Jr.
2003-Nov-05 11:52 UTC
[Shorewall-users] Shorewall and 2.6.0-test9 kernel
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thanks a lot. I will try to compile my kernel later today and see if I can get Shorewall running again. Kevin On Wednesday 05 November 2003 1:56 am, Milos Wimmer wrote:> On Tue, 4 Nov 2003, Kevin Miller, Jr. wrote: > > Has anyone got Shorewall to work with the 2.6.0-test9 kernel? If so, I > > would be curious to see your kernel configs so I can get my firewall > > working again. > > Yes, I have it (2.6.0-test9-bk1). My config file is in attachment. > > I would like to ask about related thing. Is here any recommendation or > plans how to use Shorewall together with native IPsec in 2.6 kernel? > This new kernel code does not create "ipsec" device and so (I think) > we cannot use traditional shorewall technique for "ipsec rules". > > Regards, > Milos Wimmer > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Milos Wimmer > Internet Services Specialist e-mail: wimmer@zcu.cz > Laboratory for Computer Science > University of West Bohemia phone : +420 377 632 843 > Univerzitni 8, 306 14 Plzen fax : +420 377 421 419 > Czech Republic, Europe WWW : http://www.zcu.cz/~wimmer/ > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~- -- Kevin Miller, Jr. Masters of Public Affairs, Comparative and International Affairs, Information Systems, and Nonprofit Management, School of Public and Environmental Affairs Indiana University - Bloomington http://www.amerasianworld.com kevmille@e-civilsociety.org mobile: 812-219-5047 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/qVTJP2TQUAjSykARAuqOAJ9wgBm7JlzpZEFXgamQt2l4oa7iYwCgh464 iyH+g8rt2xoOSHi6Rj8EhJA=Rskm -----END PGP SIGNATURE-----
On Wed, 5 Nov 2003, David T Hollis wrote:> If I drop Shorewall on both ends, IPSEC works fine. With Shorewall up, > I get the above. Looking at the packets with Ethereal, the decrypted > traffic is totally hosed up. There are IPv3 (yes 3) headers and such > and the destination address is obviously dorked up.I tried to connect single host in Internet to firewall with Shorewall and IPSec gateway (with PSK, racoon and tunnel mode). It works nice and fine. But I have problem to set appropriate shorewall rules for accepting of traffic going through IPsec tunnel into private network. Kernel 2.6 has no virtual ipsec interface. Data of remote single host are decrypted on IPsec end point on the firewall and Shorewall sees them as data coming from IP address of single host in Internet to external interface (Net zone) of firewall (Shorewall writes it into the log so). But how to determine that these data are coming through IPsec tunnel and not directly? Maybe some "iptables -A POSTROUTING" rules could help... I agree - kernel 2.6 is future technology today and "global" solution of this problem will be much better than some partial steps. Regards, Milos ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Milos Wimmer Internet Services Specialist e-mail: wimmer@zcu.cz Laboratory for Computer Science University of West Bohemia phone : +420 377 632 843 Univerzitni 8, 306 14 Plzen fax : +420 377 421 419 Czech Republic, Europe WWW : http://www.zcu.cz/~wimmer/ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
On Wed, 2003-11-05 at 16:26, Milos Wimmer wrote:> On Wed, 5 Nov 2003, David T Hollis wrote: > > > If I drop Shorewall on both ends, IPSEC works fine. With Shorewall up, > > I get the above. Looking at the packets with Ethereal, the decrypted > > traffic is totally hosed up. There are IPv3 (yes 3) headers and such > > and the destination address is obviously dorked up. > > I tried to connect single host in Internet to firewall with Shorewall and > IPSec gateway (with PSK, racoon and tunnel mode). It works nice and fine. > > But I have problem to set appropriate shorewall rules for accepting of > traffic going through IPsec tunnel into private network. Kernel 2.6 has no > virtual ipsec interface. Data of remote single host are decrypted on IPsec > end point on the firewall and Shorewall sees them as data coming from IP > address of single host in Internet to external interface (Net zone) of > firewall (Shorewall writes it into the log so). > But how to determine that these data are coming through IPsec tunnel > and not directly? > Maybe some "iptables -A POSTROUTING" rules could help... > > I agree - kernel 2.6 is future technology today and "global" solution > of this problem will be much better than some partial steps. > > Regards, > Milos >I''m finally making some progress with this. The big snag seems to be the lack of a defined interface for the IPSEC traffic. I found that if I did something kludgy like: ACCEPT net:192.168.1.0/24 loc icmp 8 in my rules file, I could ping from the 192.168.1.0/24 subnet on one side of the VPN to local hosts on the other side. I''m now in the process of trying to figure out if using the multi-networks/zone approach can work. The hard part is that I don''t have one or two specific networks on my ''net'' zone, I have the VPN networks and also 0.0.0.0/0. Here''s my configs that almost get me there: Gateway #1 Configs -- interfaces: - eth0 detect dhcp,blacklist loc eth1 detect dhcp hosts: rastampa eth0:172.16.100.0/24 net eth0:0.0.0.0/0 policy: loc net ACCEPT rastampa loc ACCEPT loc rastampa ACCEPT net all DROP info Gateway #2 Configs -- interfaces: - eth0 detect loc eth1 detect dhcp hosts: dhollis eth0:192.168.1.0/24 net eth0:0.0.0.0/0 policy: loc net ACCEPT dhollis loc ACCEPT loc dhollis ACCEPT net all DROP info Pinging from gw1''s internal net to gw2s net gives me these logs on gw2: Shorewall:net2all:DROP:IN=eth0 OUT=eth1 SRC=192.168.1.164 DST=172.16.100.100 LEN=84 TOS=0x00 PREC=0x00 TTL=62 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=42531 SEQ=601 I''ve noticed that eth0_fwd gets created like this: Chain eth0_fwd (1 references) target prot opt source destination dynamic all -- 0.0.0.0/0 0.0.0.0/0 net2all all -- 0.0.0.0/0 0.0.0.0/0 net2all all -- 0.0.0.0/0 192.168.1.0/24 dhollis_frwd all -- 192.168.1.0/24 0.0.0.0/0 If eth0_fwd is tweaked to be like this: Chain eth0_fwd (1 references) target prot opt source destination dhollis_frwd all -- 192.168.1.0/24 0.0.0.0/0 dynamic all -- 0.0.0.0/0 0.0.0.0/0 net2all all -- 0.0.0.0/0 0.0.0.0/0 than it works. Reordering entries in hosts didn''t make a difference in how the chain created. Any other tricks to influence the ordering?
> On Wed, 2003-11-05 at 16:26, Milos Wimmer wrote: >> _fwd gets created like this: > > Chain eth0_fwd (1 references) > target prot opt source destination > dynamic all -- 0.0.0.0/0 0.0.0.0/0 > net2all all -- 0.0.0.0/0 0.0.0.0/0 > net2all all -- 0.0.0.0/0 192.168.1.0/24 > dhollis_frwd all -- 192.168.1.0/24 0.0.0.0/0 > > > If eth0_fwd is tweaked to be like this: > > Chain eth0_fwd (1 references) > target prot opt source destination > dhollis_frwd all -- 192.168.1.0/24 0.0.0.0/0 > dynamic all -- 0.0.0.0/0 0.0.0.0/0 > net2all all -- 0.0.0.0/0 0.0.0.0/0 > > > than it works. > > Reordering entries in hosts didn''t make a difference in how the chain > created. Any other tricks to influence the ordering? >Rules are always created in zone order so you need to reorder the zone file. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline \ http://www.shorewall.net Washington, USA \ teastep@shorewall.net
On Thu, 2003-11-06 at 16:11, Tom Eastep wrote:> > On Wed, 2003-11-05 at 16:26, Milos Wimmer wrote: > >> _fwd gets created like this: > > > > Chain eth0_fwd (1 references) > > target prot opt source destination > > dynamic all -- 0.0.0.0/0 0.0.0.0/0 > > net2all all -- 0.0.0.0/0 0.0.0.0/0 > > net2all all -- 0.0.0.0/0 192.168.1.0/24 > > dhollis_frwd all -- 192.168.1.0/24 0.0.0.0/0 > > > > > > If eth0_fwd is tweaked to be like this: > > > > Chain eth0_fwd (1 references) > > target prot opt source destination > > dhollis_frwd all -- 192.168.1.0/24 0.0.0.0/0 > > dynamic all -- 0.0.0.0/0 0.0.0.0/0 > > net2all all -- 0.0.0.0/0 0.0.0.0/0 > > > > > > than it works. > > > > Reordering entries in hosts didn''t make a difference in how the chain > > created. Any other tricks to influence the ordering? > > > > Rules are always created in zone order so you need to reorder the zone file. > > -TomSweet! That worked. Moving my VPN zones to the top of the list made the ethX_fwd chains come up correctly and things seem to be rolling.