Let´s change Now we have a VPN as documented many times. Two gates, two subnets, that´s all. Host 1 isn´t any longer involved in the vpn but host >>>1<<< is at this point the left side gateway. To Now we have a VPN as documented many times. Two gates, two subnets, that´s all. Host 1 isn´t any longer involved in the vpn but host >>>2<<< is at this point the left side gateway. -----Ursprüngliche Nachricht----- Von: shorewall-users-admin@lists.sourceforge.net [mailto:shorewall-users-admin@lists.sourceforge.net] Im Auftrag von info@kws-netzwerke.de Gesendet: Dienstag, 7. Februar 2006 14:40 An: shorewall-users@lists.sourceforge.net Betreff: [Shorewall-users] proxyarp <--> OpenSwan VPN/Internet Our VPN runs for 3 months very well with a minimum of traffic <100 kbit/s. Only DNS Zones and nagios passive checks were transferred. Everything seems to work. Left side is x.x.x.14 (host 1) Subnet 10.0.0.0/24 openswan 2.4.4 shorewall 2.4.2 & iptables 1.3.4 gentoo 2.6.12-r9 with policy match It´s reachable through a proxyarp entry on x.x.x.11 (host 2) which is another gentoo 2.6.12-r9 with shorewall 2.4.1 and iptables 1.3.2. At this point this shorewall has nothing to do with the vpn but allows the traffic generally to x.x.x.14 Right side is y.y.y.212 (host 3) Subnet 10.10.10.0/24 openswan 2.3.0 shorewall 2.4.1 & iptables 1.3.2 gentoo 2.6.12-r9 with policy match Now let´s say that I am a host with subnet 10.0.0.0/24. I am able to ping subnet 10.10.10.0/24 very well (best latency without loss). I am able to transfer DNS zone data very well. I am able to transfer nagios passive checks very well. I am not able to cp/cpio/rsync (nfs), sftp or else to subnet 10.10.10.0/24 very well or let´s say I am able to transfer but within a few seconds my bandwith goes down <100kbit/s and changes permanently to stalled. The connection is still alive but it will take one day to transfer 20MB?!. First of all I thought it has something to do with VPN revisions or settings. So I decided to kill proxyarp host 1 and setup another openswan 2.3.0 on host 2. Now we have a VPN as documented many times. Two gates, two subnets, that´s all. Host 1 isn´t any longer involved in the vpn but host 1 is at this point the left side gateway. Now everything works well. I started to be in doubt about the VPN to be the source of my problems and I started a stupid sftp job from host 1 out of any vpn through the public internet. Host 1 is still an entry in host 2´s shorewall proxyarp. This job went down, too. I think I have a problem with proxyarp, shorewall versions or else. Is there anyone who knows about? Cheers Mike ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=k&kid3432&bid#0486&dat1642 _______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
Hi Mike, next time please read and follow the support guidelines. Between much unnecassary information I found this:> I am able to ping subnet 10.10.10.0/24 very well (best latency without > loss). > I am able to transfer DNS zone data very well. > I am able to transfer nagios passive checks very well. > I am not able to cp/cpio/rsync (nfs), sftp or else to subnet 10.10.10.0/24 > very well or let´s say I am able to transfer but within a few seconds my > bandwith goes down <100kbit/s and changes permanently to stalled. > > The connection is still alive but it will take one day to transfer 20MB?!. > >So this look like a MTU problem (Path MTU disovery doesn''t work). This problem hits you when you transfer bigger IP packets. This is not so much shorewall related, but of course shorewall has a solution for you. In newer versions of shorewall you want to set the MSS by editing /etc/shorewall/zone to something like this: vpn0 ipsec mode=tunnel mss=1384 mss=1384 Play around with these incoming and outgoing values to find the best setup for your case. In older Versions of shorewall those settings were located in /etc/shorewall/ipsec file. I can''t remember when the this change was introduced into shorewall. But you''ll find out yourself by reading the comments on top of those files. HTH, Alex ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
I´ve tried to play with mss values in /et c/shorewall/ipsec vpn yes mode=tunnel mss=1400(1500,1384,1416,1452,1344) After all I decided to leave /etc/shorewall/ipsec empty. Further the problem seems to be out of the tunnel, too. I think ipsec file won´t help with issues out of the ipsec tunnel. In my VPN working environment there is also an empty /etc/shorewall/ipsec file and it works. The problem seems to be based out of the tunnel but of course has negative effects to the tunnel. What about clampmss=Yes or clampmss=1400(1384,1500...) in /etc/shorewall/shorewall.conf Could this provide a solution? Curious to me is that pmtu is only discovered by using proxyarp. If proxyarp is disabled everything is working fine. -----Ursprüngliche Nachricht----- Von: shorewall-users-admin@lists.sourceforge.net [mailto:shorewall-users-admin@lists.sourceforge.net] Im Auftrag von Alexander Wilms Gesendet: Dienstag, 7. Februar 2006 15:32 An: shorewall-users@lists.sourceforge.net Betreff: Re: WG: [Shorewall-users] proxyarp <--> OpenSwan VPN/Internet Hi Mike, next time please read and follow the support guidelines. Between much unnecassary information I found this:> I am able to ping subnet 10.10.10.0/24 very well (best latency without > loss). > I am able to transfer DNS zone data very well. > I am able to transfer nagios passive checks very well. > I am not able to cp/cpio/rsync (nfs), sftp or else to subnet 10.10.10.0/24 > very well or let´s say I am able to transfer but within a few seconds my > bandwith goes down <100kbit/s and changes permanently to stalled. > > The connection is still alive but it will take one day to transfer 20MB?!. > >So this look like a MTU problem (Path MTU disovery doesn''t work). This problem hits you when you transfer bigger IP packets. This is not so much shorewall related, but of course shorewall has a solution for you. In newer versions of shorewall you want to set the MSS by editing /etc/shorewall/zone to something like this: vpn0 ipsec mode=tunnel mss=1384 mss=1384 Play around with these incoming and outgoing values to find the best setup for your case. In older Versions of shorewall those settings were located in /etc/shorewall/ipsec file. I can''t remember when the this change was introduced into shorewall. But you''ll find out yourself by reading the comments on top of those files. HTH, Alex ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 _______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
On Tuesday 07 February 2006 07:01, info@kws-netzwerke.de wrote:> I´ve tried to play with mss values in /et c/shorewall/ipsec > > vpn yes mode=tunnel mss=1400(1500,1384,1416,1452,1344)Which version of Shorewall are you running and what is your setting for IPSECFILE (if any) in /etc/shorewall/shorewall.conf?> > After all I decided to leave /etc/shorewall/ipsec empty. Further the > problem seems to be out of the tunnel, too. I think ipsec file won´t help > with issues out of the ipsec tunnel. >That''s exactly what it''s for! -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: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
info@kws-netzwerke.de schrieb:> I´ve tried to play with mss values in /etc/shorewall/ipsec > > vpn yes mode=tunnel mss=1400(1500,1384,1416,1452,1344) > >Start with a lower value of 1300 and did you understand that there are OUT and IN options? Also keep in mind that you will have to play with those options on BOTH sides of the tunnel. ( you use 2 subnets behind 2 gateways, right?) So to keep it easy for the beginning, just use an mss value of 1300 for IN and OUT on BOTH sides. Optimization can be done later.> After all I decided to leave /etc/shorewall/ipsec empty. Further the problem > seems to be out of the tunnel, too. I think ipsec file won´t help with > issues out of the ipsec tunnel. > > In my VPN working environment there is also an empty /etc/shorewall/ipsec > file and it works. >Completely empty? Then you will have in "zones" file because of using newer shorewall version. (btw, I asked Tom, change from ipsec to zones was introduced in 3.0)> The problem seems to be based out of the tunnel but of course has negative > effects to the tunnel. > > What about clampmss=Yes or clampmss=1400(1384,1500...) in > /etc/shorewall/shorewall.conf Could this provide a solution? > >This sets the general MTU of the underlaying DSL(?) link, not the MSS value within the tunnel. But yes, if you use DSL, set it to yes, at least it works for me.> Curious to me is that pmtu is only discovered by using proxyarp. If proxyarp > is disabled everything is working fine. > >No idea about the connection to proxyarp (if there is one). Just from my own experience: I switched to another DSL provider and suddenly the problem occured. This seemed to be related to the fact that german DSL providers use a tunnel technology to use the original T-Com backbone. And somehow the path MTU discovery got stuck somewhere on the way. I discussed that with Tom and the result was that he implemeted the mss value. Btw, really read the support guidelines and post the requested information. You know, my crystal ball is in repair at the moment. So please also explain how your proxyarp setup fits into this picture. Alex ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
<info@kws-netzwerke.de>
2006-Feb-07 20:08 UTC
AW: AW: WG: proxyarp <--> OpenSwan VPN/Internet
I´ve tried on both vpn gateways /etc/shorewall/ipsec vpn yes mode=tunnel mss=1300 mss=1300 In addition I switched /etc/shorewall/shorewall.conf clampmss on both sides to =Yes. (sometimes to 1300/1400/1500) /etc/shorewall/proxyarp config on a third box (x.x.x.11) is this. x.x.x.14 eth2 eth0 No The left VPN gateway is x.x.x.14 which is in the dmz from x.x.x.11 And I´ve tried to leave /etc/shorewall/ipsec empty. As I mentioned before I have the troubles out of the tunnel, too. So I don´t think it has anything to do with /etc/shorewall/ipsec. Both ways are working with small traffic but if you transfer a 20MB file the tunnel goes down to 10 kbyte and sometimes stalled. An sftp job out of the tunnel goes down, too, but only if vpn gateway is configured through proxyarp on an additional box. When I configure without proxyarp - without any dmz - it work´s. I think another provider won´t be the solution. Cheers Mike -----Ursprüngliche Nachricht----- Von: shorewall-users-admin@lists.sourceforge.net [mailto:shorewall-users-admin@lists.sourceforge.net] Im Auftrag von Alexander Wilms Gesendet: Dienstag, 7. Februar 2006 16:43 An: shorewall-users@lists.sourceforge.net Betreff: Re: AW: WG: [Shorewall-users] proxyarp <--> OpenSwan VPN/Internet info@kws-netzwerke.de schrieb:> I´ve tried to play with mss values in /etc/shorewall/ipsec > > vpn yes mode=tunnel mss=1400(1500,1384,1416,1452,1344) > >Start with a lower value of 1300 and did you understand that there are OUT and IN options? Also keep in mind that you will have to play with those options on BOTH sides of the tunnel. ( you use 2 subnets behind 2 gateways, right?) So to keep it easy for the beginning, just use an mss value of 1300 for IN and OUT on BOTH sides. Optimization can be done later.> After all I decided to leave /etc/shorewall/ipsec empty. Further theproblem> seems to be out of the tunnel, too. I think ipsec file won´t help with > issues out of the ipsec tunnel. > > In my VPN working environment there is also an empty /etc/shorewall/ipsec > file and it works. >Completely empty? Then you will have in "zones" file because of using newer shorewall version. (btw, I asked Tom, change from ipsec to zones was introduced in 3.0)> The problem seems to be based out of the tunnel but of course has negative > effects to the tunnel. > > What about clampmss=Yes or clampmss=1400(1384,1500...) in > /etc/shorewall/shorewall.conf Could this provide a solution? > >This sets the general MTU of the underlaying DSL(?) link, not the MSS value within the tunnel. But yes, if you use DSL, set it to yes, at least it works for me.> Curious to me is that pmtu is only discovered by using proxyarp. Ifproxyarp> is disabled everything is working fine. > >No idea about the connection to proxyarp (if there is one). Just from my own experience: I switched to another DSL provider and suddenly the problem occured. This seemed to be related to the fact that german DSL providers use a tunnel technology to use the original T-Com backbone. And somehow the path MTU discovery got stuck somewhere on the way. I discussed that with Tom and the result was that he implemeted the mss value. Btw, really read the support guidelines and post the requested information. You know, my crystal ball is in repair at the moment. So please also explain how your proxyarp setup fits into this picture. Alex ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 _______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
<info@kws-netzwerke.de>
2006-Feb-07 20:17 UTC
AW: AW: WG: proxyarp <--> OpenSwan VPN/Internet
Shorewall 2.4.2 on left vpn gate with ip x.x.x.14 Shorewall 2.4.1 on right gate with ip y.y.y.212 Shorewall 2.4.1 on fw with ip x.x.x.11 and /etc/shorewall/proxyarp x.x.x.14 eth2 eth0 No I don´t know any IPSEC settings in /etc/shorewall/sohrewall.conf. I only know about /etc/shorewall/ipsec and tried out many things like this. vpn yes mode=tunnel mss=1300(1400/1500) mss=1300(1400/1500) At this point I don´t think that it has anything to do with /etc/shorewall/ipsec, openswan or anything from the vpn. The troubles are always present if I start transfer jobs from x.x.x.14 (through the tunnel and through the public internet) which is configured in /etc/shorewall/proxyarp in another box with ip x.x.x.11. x.x.x.11 is the one which is connected to my sdsl provider. Cheers Mike -----Ursprüngliche Nachricht----- Von: shorewall-users-admin@lists.sourceforge.net [mailto:shorewall-users-admin@lists.sourceforge.net] Im Auftrag von Tom Eastep Gesendet: Dienstag, 7. Februar 2006 16:13 An: shorewall-users@lists.sourceforge.net Betreff: Re: AW: WG: [Shorewall-users] proxyarp <--> OpenSwan VPN/Internet On Tuesday 07 February 2006 07:01, info@kws-netzwerke.de wrote:> I´ve tried to play with mss values in /et c/shorewall/ipsec > > vpn yes mode=tunnel mss=1400(1500,1384,1416,1452,1344)Which version of Shorewall are you running and what is your setting for IPSECFILE (if any) in /etc/shorewall/shorewall.conf?> > After all I decided to leave /etc/shorewall/ipsec empty. Further the > problem seems to be out of the tunnel, too. I think ipsec file won´t help > with issues out of the ipsec tunnel. >That''s exactly what it''s for! -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: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=k&kid3432&bid#0486&dat1642 _______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
Hi Mike, I''m sorry, but for now I have to give up. Because I really don''t get the big picture of your setup. Maybe somebody else on the list understands what you are trying to do. Alex On Tuesday 07 February 2006 21:17, info@kws-netzwerke.de wrote:> Shorewall 2.4.2 on left vpn gate with ip x.x.x.14 > Shorewall 2.4.1 on right gate with ip y.y.y.212 > Shorewall 2.4.1 on fw with ip x.x.x.11 and /etc/shorewall/proxyarp x.x.x.14 > eth2 eth0 No > > I don´t know any IPSEC settings in /etc/shorewall/sohrewall.conf. I only > know about /etc/shorewall/ipsec and tried out many things like this. > > vpn yes mode=tunnel mss=1300(1400/1500) > mss=1300(1400/1500) > > At this point I don´t think that it has anything to do with > /etc/shorewall/ipsec, openswan or anything from the vpn. The troubles are > always present if I start transfer jobs from x.x.x.14 (through the tunnel > and through the public internet) which is configured in > /etc/shorewall/proxyarp in another box with ip x.x.x.11. x.x.x.11 is the > one which is connected to my sdsl provider. > > Cheers > Mike >------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
<info@kws-netzwerke.de>
2006-Feb-08 10:15 UTC
AW: AW: AW: WG: proxyarp <--> OpenSwan VPN/Internet
Hey Alex, I´m just in trying to operate successfully with my shorewall host in another shorewall´s dmz but the simplest transfer job to the internet doesn´t work well. After all the mss or clampmss won´t help. The problem seems to be based on other sources. I´ll start upgrading versions, kernels, use other nic´s, cables, switches... At this point packet loss or stalling between shorewall host in dmz and internet (through another shorewall) is still present. Anyway, many thanks to you for your support. Cheers Mike -----Ursprüngliche Nachricht----- Von: shorewall-users-admin@lists.sourceforge.net [mailto:shorewall-users-admin@lists.sourceforge.net] Im Auftrag von Alexander Wilms Gesendet: Mittwoch, 8. Februar 2006 09:03 An: shorewall-users@lists.sourceforge.net Betreff: Re: AW: AW: WG: [Shorewall-users] proxyarp <--> OpenSwan VPN/Internet Hi Mike, I''m sorry, but for now I have to give up. Because I really don''t get the big picture of your setup. Maybe somebody else on the list understands what you are trying to do. Alex On Tuesday 07 February 2006 21:17, info@kws-netzwerke.de wrote:> Shorewall 2.4.2 on left vpn gate with ip x.x.x.14 > Shorewall 2.4.1 on right gate with ip y.y.y.212 > Shorewall 2.4.1 on fw with ip x.x.x.11 and /etc/shorewall/proxyarpx.x.x.14> eth2 eth0 No > > I don´t know any IPSEC settings in /etc/shorewall/sohrewall.conf. I only > know about /etc/shorewall/ipsec and tried out many things like this. > > vpn yes mode=tunnel mss=1300(1400/1500) > mss=1300(1400/1500) > > At this point I don´t think that it has anything to do with > /etc/shorewall/ipsec, openswan or anything from the vpn. The troubles are > always present if I start transfer jobs from x.x.x.14 (through the tunnel > and through the public internet) which is configured in > /etc/shorewall/proxyarp in another box with ip x.x.x.11. x.x.x.11 is the > one which is connected to my sdsl provider. > > Cheers > Mike >------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=k&kid3432&bid#0486&dat1642 _______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
On Wednesday 08 February 2006 02:15, info@kws-netzwerke.de wrote:> Hey Alex, > > I´m just in trying to operate successfully with my shorewall host in > another shorewall´s dmz but the simplest transfer job to the internet > doesn´t work well. >From the information Mike sent me privately, it appears that the problem is with the definition of the default gateway on vpn-gw. It is set to 82.100.235.1 which is not on the same lan segment (it is accessed via eth0 on gentoo-pfw). But gentoo-pfw isn''t proxying ARP for that system. I suggest setting the default gateway at vpn-gw to be one of the 82.100.235.0/28 addresses on gentoo-pfw. -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: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
<info@kws-netzwerke.de>
2006-Feb-09 20:55 UTC
AW: AW: AW: AW: WG: proxyarp <--> OpenSwan VPN/Internet
On Thursday 09 February 2006 16:29, teastep@shorewall.net wrote:> From the information Mike sent me privately, it appears that the problem > is > with the definition of the default gateway on vpn-gw. It is set to > 82.100.235.1 which is not on the same lan segment (it is accessed via eth0 > on > gentoo-pfw). But gentoo-pfw isn''t proxying ARP for that system. > > I suggest setting the default gateway at vpn-gw to be one of the > 82.100.235.0/28 addresses on gentoo-pfw.I´ve done my work exactly as written with shorewall documentation >"but should have the same default gateway as the firewall itself"< and it works one-way. As I understood, /etc/shorewall/proxyarp is the file which manages logically the problem, that the default gw and the dmz host aren´t physically in the same subnet. Now I´ve changed my default gw on vpn-gw to 82.100.235.11 as you suggested. Everything is the same. Downloads from vpn-gw and uploads to vpn-gw are working well, uploads from vpn-gw are still going down to a minimum of kilobits. It looks like a kind of upload shaping but this box doesn´t know anything about shaping, QOS or else - job is still miserable+2. All in all I would soft-confirm, that there is a routing or proxying ARP problem. But where the deuce did it hide itself or better, who/which app./version can provide a solution? I have to questions beside the one for the solution. Does anyone know about problems with ARP and kernel 2.6.12-r9, especially with shorewall proxyarp? Is it necessary to compile arpd to make shorewall´s proxyarp working well or is there an in-shorewall-integrated component which handles ARP dialogues? Thanks to all of your support. Cheers Mike -----Ursprüngliche Nachricht----- Von: shorewall-users-admin@lists.sourceforge.net [mailto:shorewall-users-admin@lists.sourceforge.net] Im Auftrag von Tom Eastep Gesendet: Donnerstag, 9. Februar 2006 16:29 An: shorewall-users@lists.sourceforge.net Betreff: Re: AW: AW: AW: WG: [Shorewall-users] proxyarp <--> OpenSwan VPN/Internet On Wednesday 08 February 2006 02:15, info@kws-netzwerke.de wrote:> Hey Alex, > > I´m just in trying to operate successfully with my shorewall host in > another shorewall´s dmz but the simplest transfer job to the internet > doesn´t work well. >From the information Mike sent me privately, it appears that the problem is with the definition of the default gateway on vpn-gw. It is set to 82.100.235.1 which is not on the same lan segment (it is accessed via eth0 on gentoo-pfw). But gentoo-pfw isn''t proxying ARP for that system. I suggest setting the default gateway at vpn-gw to be one of the 82.100.235.0/28 addresses on gentoo-pfw. -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: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=k&kid3432&bid#0486&dat1642 _______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
Tom Eastep
2006-Feb-09 21:06 UTC
Re: AW: AW: AW: AW: WG: proxyarp <--> OpenSwan VPN/Internet
On Thursday 09 February 2006 12:55, info@kws-netzwerke.de wrote:> On Thursday 09 February 2006 16:29, teastep@shorewall.net wrote: > > From the information Mike sent me privately, it appears that the problem > > is > > with the definition of the default gateway on vpn-gw. It is set to > > 82.100.235.1 which is not on the same lan segment (it is accessed via > > eth0 on > > gentoo-pfw). But gentoo-pfw isn''t proxying ARP for that system. > > > > I suggest setting the default gateway at vpn-gw to be one of the > > 82.100.235.0/28 addresses on gentoo-pfw. > > I´ve done my work exactly as written with shorewall documentation >"but > should have the same default gateway as the firewall itself"< and it works > one-way.NO YOU HAVE NOT!!! You have configured Proxy ARP on vpn-fw and on that system, you have specified a default gateway that isn''t on the same LAN.> > As I understood, /etc/shorewall/proxyarp is the file which manages > logically the problem, that the default gw and the dmz host aren´t > physically in the same subnet.Again, your setup is NOT like anything in my documetation.> > Now I´ve changed my default gw on vpn-gw to 82.100.235.11 as you suggested. > Everything is the same. Downloads from vpn-gw and uploads to vpn-gw are > working well, uploads from vpn-gw are still going down to a minimum of > kilobits. It looks like a kind of upload shaping but this box doesn´t know > anything about shaping, QOS or else - job is still miserable+2. > > All in all I would soft-confirm, that there is a routing or proxying ARP > problem. But where the deuce did it hide itself or better, who/which > app./version can provide a solution? > > I have to questions beside the one for the solution. > > Does anyone know about problems with ARP and kernel 2.6.12-r9, especially > with shorewall proxyarp? > > Is it necessary to compile arpd to make shorewall´s proxyarp working well > or is there an in-shorewall-integrated component which handles ARP > dialogues?I suggest that you learn to use a traffic analyzer like Ethereal and look to see what is actually happening. -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
Tom Eastep
2006-Feb-09 21:14 UTC
Re: AW: AW: AW: AW: WG: proxyarp <--> OpenSwan VPN/Internet
On Thursday 09 February 2006 13:06, Tom Eastep wrote:> > I suggest that you learn to use a traffic analyzer like Ethereal and look > to see what is actually happening. >Also -- does the upstream cicso router route all 82.x.x.x traffic via a fixed IP address on gentoo-pfw? If not, then you need to configure Proxy ARP on that box as well. -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: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
Tom Eastep
2006-Feb-09 21:18 UTC
Re: AW: AW: AW: AW: WG: proxyarp <--> OpenSwan VPN/Internet
On Thursday 09 February 2006 13:06, Tom Eastep wrote:> On Thursday 09 February 2006 12:55, info@kws-netzwerke.de wrote: > > On Thursday 09 February 2006 16:29, teastep@shorewall.net wrote: > > > From the information Mike sent me privately, it appears that the > > > problem is > > > with the definition of the default gateway on vpn-gw. It is set to > > > 82.100.235.1 which is not on the same lan segment (it is accessed via > > > eth0 on > > > gentoo-pfw). But gentoo-pfw isn''t proxying ARP for that system. > > > > > > I suggest setting the default gateway at vpn-gw to be one of the > > > 82.100.235.0/28 addresses on gentoo-pfw. > > > > I´ve done my work exactly as written with shorewall documentation >"but > > should have the same default gateway as the firewall itself"< and it > > works one-way. > > NO YOU HAVE NOT!!! You have configured Proxy ARP on vpn-fw and on that > system, you have specified a default gateway that isn''t on the same LAN. >Ok -- I''ll scrape the egg off of my face now. I confused the two status reports that you sent. Please disregard all of my irrational ramblings above. I have no idea what your problem is -- and I''ll stand by my recommendation to look at the traffic using Ethereal. -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: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
Tom Eastep
2006-Feb-09 21:23 UTC
Re: AW: AW: AW: AW: WG: proxyarp <--> OpenSwan VPN/Internet
On Thursday 09 February 2006 13:14, Tom Eastep wrote:> On Thursday 09 February 2006 13:06, Tom Eastep wrote: > > I suggest that you learn to use a traffic analyzer like Ethereal and look > > to see what is actually happening. > > Also -- does the upstream cicso router route all 82.x.x.x traffic via a > fixed IP address on gentoo-pfw? If not, then you need to configure Proxy > ARP on that box as well.Also, please disregard this post. -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: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
<info@kws-netzwerke.de>
2006-Feb-09 21:30 UTC
AW: AW: AW: AW: AW: WG: proxyarp <--> OpenSwan VPN/Internet
On Thursday 09 February 2006 13:06, Tom Eastep wrote:> Please disregard all of my irrational ramblings above.Ok, no prob, thanks for notification.> I suggest that you learn to use a traffic analyzer like Ethereal and > look to see what is actually happening.I think it´s time, too.> Also -- does the upstream cicso router route all 82.x.x.x traffic via a > fixed IP address on gentoo-pfw? If not, then you need to configure Proxy > ARP on that box as well.Could this have anything to do with it? No, it does not route to a fixed ip on gentoo-pfw. It´s member of the subnet and providers backbone router routes 82.100.235.0/28 to a ppp assigned wan interface with my cisco upstream router. I will try to play. Cheers Mike -----Ursprüngliche Nachricht----- Von: shorewall-users-admin@lists.sourceforge.net [mailto:shorewall-users-admin@lists.sourceforge.net] Im Auftrag von Tom Eastep Gesendet: Donnerstag, 9. Februar 2006 22:19 An: shorewall-users@lists.sourceforge.net Betreff: Re: AW: AW: AW: AW: WG: [Shorewall-users] proxyarp <--> OpenSwan VPN/Internet On Thursday 09 February 2006 13:06, Tom Eastep wrote:> On Thursday 09 February 2006 12:55, info@kws-netzwerke.de wrote: > > On Thursday 09 February 2006 16:29, teastep@shorewall.net wrote: > > > From the information Mike sent me privately, it appears that the > > > problem is > > > with the definition of the default gateway on vpn-gw. It is set to > > > 82.100.235.1 which is not on the same lan segment (it is accessed via > > > eth0 on > > > gentoo-pfw). But gentoo-pfw isn''t proxying ARP for that system. > > > > > > I suggest setting the default gateway at vpn-gw to be one of the > > > 82.100.235.0/28 addresses on gentoo-pfw. > > > > I´ve done my work exactly as written with shorewall documentation >"but > > should have the same default gateway as the firewall itself"< and it > > works one-way. > > NO YOU HAVE NOT!!! You have configured Proxy ARP on vpn-fw and on that > system, you have specified a default gateway that isn''t on the same LAN. >Ok -- I''ll scrape the egg off of my face now. I confused the two status reports that you sent. Please disregard all of my irrational ramblings above. I have no idea what your problem is -- and I''ll stand by my recommendation to look at the traffic using Ethereal. -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: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=k&kid3432&bid#0486&dat1642 _______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
<info@kws-netzwerke.de>
2006-Feb-09 21:34 UTC
AW: AW: AW: AW: AW: WG: proxyarp <--> OpenSwan VPN/Internet
On Thursday 09 February 2006 13:14, Tom Eastep wrote:> Also, please disregard this post.Oh, of course I will do and stop playing with that. Ok, we are at the end of all our ideas. I´ll keep on trying and will send info soon after triumph over my boxes. Cheers Mike -----Ursprüngliche Nachricht----- Von: shorewall-users-admin@lists.sourceforge.net [mailto:shorewall-users-admin@lists.sourceforge.net] Im Auftrag von Tom Eastep Gesendet: Donnerstag, 9. Februar 2006 22:23 An: shorewall-users@lists.sourceforge.net Betreff: Re: AW: AW: AW: AW: WG: [Shorewall-users] proxyarp <--> OpenSwan VPN/Internet On Thursday 09 February 2006 13:14, Tom Eastep wrote:> On Thursday 09 February 2006 13:06, Tom Eastep wrote: > > I suggest that you learn to use a traffic analyzer like Ethereal andlook> > to see what is actually happening. > > Also -- does the upstream cicso router route all 82.x.x.x traffic via a > fixed IP address on gentoo-pfw? If not, then you need to configure Proxy > ARP on that box as well.Also, please disregard this post. -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: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 _______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
Tom Eastep
2006-Feb-09 21:42 UTC
Re: AW: AW: AW: AW: AW: WG: proxyarp <--> OpenSwan VPN/Internet
On Thursday 09 February 2006 13:30, info@kws-netzwerke.de wrote:> On Thursday 09 February 2006 13:06, Tom Eastep wrote: > > Please disregard all of my irrational ramblings above. > > Ok, no prob, thanks for notification. > > > I suggest that you learn to use a traffic analyzer like Ethereal and > > look to see what is actually happening. > > I think it´s time, too. > > > Also -- does the upstream cicso router route all 82.x.x.x traffic via a > > fixed IP address on gentoo-pfw? If not, then you need to configure Proxy > > ARP on that box as well. > > Could this have anything to do with it? > No, it does not route to a fixed ip on gentoo-pfw. It´s member of the > subnet and providers backbone router routes 82.100.235.0/28 to a ppp > assigned wan interface with my cisco upstream router. I will try to play. >The ARP caches on both firewalls look fine -- so there is no problem that I can see there. So long as you can ping the Cisco from vpn-gw, there is no problem with Proxy ARP at all. And if there was a problem, you would be able to see unanswered ARP "who-as" requests using Ethereal. Usually when Proxy ARP isn''t working, you nave NO communication, not slow communication. Very slow traffic often is caused by link level errors -- but there haven''t been any at all on either box in your case. Physical network configuration problems (lans being bridged when you don''t intend for them to be) can cause intermittent performance problems but you will usually also see nonsensical connection requests being logged by Netfilter (traffic entering the firewall on the wrong interface); I don''t see any of that in the dumps you sent. So again, I don''t see anything in the dumps that looks wrong (so long as I manage to remember which dump is which :-) -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: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
<info@kws-netzwerke.de>
2006-Feb-09 22:00 UTC
AW: AW: AW: AW: AW: AW: WG: proxyarp <--> OpenSwan VPN/Internet
Many thanks for this great statement. I am with you, that there is no configuration failure left - but maybe a mini-bug with any box, protocol or version?! tcpdump is doing its job all the time in the background and as I understood this tool, there is everything as it should be. Ethereal will start as a parallel service, too. Two eyes will watch more efficient than one does. With superior motivation I will spend another night to my small big problem. I´ll come back to you after problem is fixed or after flying the white flag by myself. Cheers Mike -----Ursprüngliche Nachricht----- Von: shorewall-users-admin@lists.sourceforge.net [mailto:shorewall-users-admin@lists.sourceforge.net] Im Auftrag von Tom Eastep Gesendet: Donnerstag, 9. Februar 2006 22:43 An: shorewall-users@lists.sourceforge.net Betreff: Re: AW: AW: AW: AW: AW: WG: [Shorewall-users] proxyarp <--> OpenSwan VPN/Internet On Thursday 09 February 2006 13:30, info@kws-netzwerke.de wrote:> On Thursday 09 February 2006 13:06, Tom Eastep wrote: > > Please disregard all of my irrational ramblings above. > > Ok, no prob, thanks for notification. > > > I suggest that you learn to use a traffic analyzer like Ethereal and > > look to see what is actually happening. > > I think it´s time, too. > > > Also -- does the upstream cicso router route all 82.x.x.x traffic via a > > fixed IP address on gentoo-pfw? If not, then you need to configure Proxy > > ARP on that box as well. > > Could this have anything to do with it? > No, it does not route to a fixed ip on gentoo-pfw. It´s member of the > subnet and providers backbone router routes 82.100.235.0/28 to a ppp > assigned wan interface with my cisco upstream router. I will try to play. >The ARP caches on both firewalls look fine -- so there is no problem that I can see there. So long as you can ping the Cisco from vpn-gw, there is no problem with Proxy ARP at all. And if there was a problem, you would be able to see unanswered ARP "who-as" requests using Ethereal. Usually when Proxy ARP isn''t working, you nave NO communication, not slow communication. Very slow traffic often is caused by link level errors -- but there haven''t been any at all on either box in your case. Physical network configuration problems (lans being bridged when you don''t intend for them to be) can cause intermittent performance problems but you will usually also see nonsensical connection requests being logged by Netfilter (traffic entering the firewall on the wrong interface); I don''t see any of that in the dumps you sent. So again, I don''t see anything in the dumps that looks wrong (so long as I manage to remember which dump is which :-) -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: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=k&kid3432&bid#0486&dat1642 _______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642