We use openvpn and shorewall extensively and it all works very well. We have a need to SNAT many address behind shorewall firewalls to private addresses on our tunneled interface so we can prevent address clashing on our VPN. In small installations (10s of addresses to nat) this works well. In large installations (100s of addresses on multiple lans) shorewall still works but slows to a crawl during the "Adding IP Addresses" in the "Activating Rules" phase. For instance one of our sites has 4 class C networks that we nat to comply with our VPN addressing. It takes over 45 minutes to load on a PIII with 512MB ram with a load well under 0.5. Below is the section where shorewall begins to slow. ---snip--- Processing /etc/shorewall/ecn... Activating Rules... Adding IP Addresses... IP Address 10.3.9.1 added to interface tun1 IP Address 10.3.9.2 added to interface tun1 IP Address 10.3.9.3 added to interface tun1 ---snip--- This goes on for all 4 class Cs and begins to slow after adding about 20 addresses. My instinct is that this is a kernel-ism. Is there something we can tweak in our kernel or can we speed up the loading through shorewall alone? This particular kernel in 2.4.18. Thanks for any hints! -- Clint Miller
Clint Miller
2003-Dec-10 16:19 UTC
Re: Large number of SNAT''d addresses loads very slowly
BTW were running v1.4.8 Shorewall. On Tuesday 09 December 2003 22:16, Clint Miller wrote:> We use openvpn and shorewall extensively and it all works very well. We > have a need to SNAT many address behind shorewall firewalls to private > addresses on our tunneled interface so we can prevent address clashing on > our VPN. In small installations (10s of addresses to nat) this works well. > In large installations (100s of addresses on multiple lans) shorewall > still works but slows to a crawl during the "Adding IP Addresses" in the > "Activating Rules" phase. For instance one of our sites has 4 class C > networks that we nat to comply with our VPN addressing. It takes over 45 > minutes to load on a PIII with 512MB ram with a load well under 0.5. > Below is the section where shorewall begins to slow. > > ---snip--- > Processing /etc/shorewall/ecn... > Activating Rules... > Adding IP Addresses... > IP Address 10.3.9.1 added to interface tun1 > IP Address 10.3.9.2 added to interface tun1 > IP Address 10.3.9.3 added to interface tun1 > ---snip--- > > This goes on for all 4 class Cs and begins to slow after adding about 20 > addresses. > > My instinct is that this is a kernel-ism. Is there something we can tweak > in our kernel or can we speed up the loading through shorewall alone? > > This particular kernel in 2.4.18. > > Thanks for any hints!
Homer Parker
2003-Dec-10 16:25 UTC
Re: Large number of SNAT''d addresses loads very slowly
On Tue, 2003-12-09 at 22:16, Clint Miller wrote:> We use openvpn and shorewall extensively and it all works very well. We have > a need to SNAT many address behind shorewall firewalls to private addresses > on our tunneled interface so we can prevent address clashing on our VPN. In > small installations (10s of addresses to nat) this works well. In large > installations (100s of addresses on multiple lans) shorewall still works but > slows to a crawl during the "Adding IP Addresses" in the "Activating Rules" > phase. For instance one of our sites has 4 class C networks that we nat to > comply with our VPN addressing. It takes over 45 minutes to load on a PIII > with 512MB ram with a load well under 0.5. Below is the section where > shorewall begins to slow.Tom has stated in the past that changing your shell in the script to ash seems to speed things up some... Worth a try.. -- Homer Parker /"\ ASCII Ribbon Campaign \ / No HTML/RTF in email http://www.homershut.net x No Word docs in email telnet://bbs.homershut.net / \ Respect for open standards "Bill Gates reports on security progress made and the challenges ahead." -- Microsoft''s Homepage, on the day an SQL Server bug crippled large sections of the Internet.
On Tuesday 09 December 2003 08:16 pm, Clint Miller wrote:> For instance one of our sites has 4 class C > networks that we nat to comply with our VPN addressing. It takes over 45 > minutes to load on a PIII with 512MB ram with a load well under 0.5. > Below is the section where shorewall begins to slow. > > ---snip--- > Processing /etc/shorewall/ecn... > Activating Rules... > Adding IP Addresses... > IP Address 10.3.9.1 added to interface tun1 > IP Address 10.3.9.2 added to interface tun1 > IP Address 10.3.9.3 added to interface tun1 > ---snip--- > > This goes on for all 4 class Cs and begins to slow after adding about 20 > addresses. > > My instinct is that this is a kernel-ism. Is there something we can tweak > in our kernel or can we speed up the loading through shorewall alone? > > This particular kernel in 2.4.18. > > Thanks for any hints!I''m absolutely speechless that someone would even dream of adding that many addresses to an interface. Given that this is a tunnel and there are no ARP or broadcast issues involved, I don''t see any need to add the addresses at all. Have you tried it without doing that? -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
Clint Miller
2003-Dec-10 21:09 UTC
Re: Large number of SNAT''d addresses loads very slowly
Tom - On Wednesday 10 December 2003 11:14, Tom Eastep wrote:> I''m absolutely speechless that someone would even dream of adding that many > addresses to an interface. > > Given that this is a tunnel and there are no ARP or broadcast issues > involved, I don''t see any need to add the addresses at all. Have you tried > it without doing that? > > -TomIt works flawlessly without adding the addresses, except... we have a set of LANs that we need to put on our VPN whose internal addresses clash with other LANs in our VPN. In order to route between the two we attach these vpn-friendly address to the tunnel interface. Then we can add routes between the new NATd lan and the rest of the VPN. The result is 192.168.0.1---snat---10.0.0.1---vpn---10.0.1.1---snat---192.168.0.1 can route between one another. It works great for a few 10s of hosts on each shorewall server. This prevents us from having to readdress the new networks we inheirit. It''s really very cool. When I was presented with the problem of routing between clashing address ranges through a VPN, I was happy to see we could do this with shorewall. However, I freely admit that this is probably a flawed solution and will happily try alternatives. Is there a better method for doing this with 100s of addresses? I''d live with it but each address added get slower and slower as it''s adding. Once the firewall activates all the rules, it works fine. But it can take an hour to load 600 addresses which makes it a little impractical. Any pointers would be greatly appreciated. Thanks! -- Clint Miller
On Wednesday 10 December 2003 01:09 pm, Clint Miller wrote:> Tom - > > On Wednesday 10 December 2003 11:14, Tom Eastep wrote: > > I''m absolutely speechless that someone would even dream of adding that > > many addresses to an interface. > > > > Given that this is a tunnel and there are no ARP or broadcast issues > > involved, I don''t see any need to add the addresses at all. Have you > > tried it without doing that? > > > > -Tom > > It works flawlessly without adding the addresses, except... > we have a set of LANs that we need to put on our VPN whose internal > addresses clash with other LANs in our VPN. In order to route between the > two we attach these vpn-friendly address to the tunnel interface. Then we > can add routes between the new NATd lan and the rest of the VPN. The > result is > > 192.168.0.1---snat---10.0.0.1---vpn---10.0.1.1---snat---192.168.0.1 > > can route between one another. >I''m saying to do that WITHOUT ADDING THE ADDRESSES to the tunnel interface! I don''t believe that they serve any purpose. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
Clint Miller
2003-Dec-10 22:16 UTC
Re: Large number of SNAT''d addresses loads very slowly
Tom - On Wednesday 10 December 2003 15:14, Tom Eastep wrote:> > I''m saying to do that WITHOUT ADDING THE ADDRESSES to the tunnel interface! > I don''t believe that they serve any purpose. > > -TomI''ve tried without adding the addresses. It doesn''t work. The route table ends up looking something like this on our central VPN server: Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.0.1 0.0.0.0 255.255.255.255 UH 0 0 0 tun1 192.168.0.1 0.0.0.0 255.255.255.255 UH 0 0 0 tun2 192.168.0.1 0.0.0.0 255.255.255.255 UH 0 0 0 tun3 xx.xx.xx.0 0.0.0.0 255.255.255.128 U 0 0 0 eth0 10.0.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 192.168.0.0 10.0.0.201 255.255.255.0 UG 0 0 0 tun1 192.168.0.0 10.0.0.203 255.255.255.0 UG 0 0 0 tun3 192.168.0.0 10.0.0.202 255.255.255.0 UG 0 0 0 tun2 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 xx.xx.xx.1 0.0.0.0 UG 0 0 0 eth0 We can only have one route to 192.168.0.0/24... right? We have about 15 LANs that are addressed 192.168.0.0/24. Another 13 that are 10.10.10.0/24. All of these are in different locations and all need to route between each other. If I''m on one LAN and try to connect to 192.168.0.20 on a remote LAN, which 192.168.0.20 am I going to get? (especially if I''m on 192.168.0.20). The first one in the route table. How would I address multiple hosts on different LANs all addressed the same? How would 2 machines both addressed 192.168.0.20 talk to one another? If we SNAT the interfaces on to the tunnels we get something that looks like this on our central VPN server: Destination Gateway Genmask Flags Metric Ref Use Iface 10.3.1.1 0.0.0.0 255.255.255.255 UH 0 0 0 tun1 10.3.2.1 0.0.0.0 255.255.255.255 UH 0 0 0 tun2 10.3.3.1 0.0.0.0 255.255.255.255 UH 0 0 0 tun3 xx.xx.xx.0 0.0.0.0 255.255.255.128 U 0 0 0 eth0 10.0.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 10.3.1.0 10.0.0.201 255.255.255.0 UG 0 0 0 tun1 10.3.2.0 10.0.0.202 255.255.255.0 UG 0 0 0 tun2 10.3.3.0 10.0.0.203 255.255.255.0 UG 0 0 0 tun3 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 xx.xx.xx.1 0.0.0.0 UG 0 0 0 eth0 This allows routes to exist to every host on every network to every other host on every network even if they have the same addresses because we can force the SNAT''d addresses to be unique. This works well and is in production (except for the new LANs with hundreds of hosts). I must be missing something or not explaining myself well. Sorry about that. -- Clint Miller
On Wednesday 10 December 2003 02:16 pm, you wrote:> Tom - > > On Wednesday 10 December 2003 15:14, Tom Eastep wrote: > > I''m saying to do that WITHOUT ADDING THE ADDRESSES to the tunnel > > interface! I don''t believe that they serve any purpose. > > > > -Tom > > I''ve tried without adding the addresses. It doesn''t work. The route table > ends up looking something like this on our central VPN server: > >Routes and aliases have *nothing* to do with one another: a) Leave the routing the way it is. b) Leave all NAT the way it is. c) Just don''t add the 100s of extra addresses to the tun* interface. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
I have a smiliar setup where I need to SNAT each subscribers private ip(s) to one single public IP address. I was using Shorewall with the above setup with 3 class "C" pools configured onto one single dummy interface. But, the IP address(s) are added to dummy interface by a custom script. Venkatesh K ----- Original Message ----- From: "Tom Eastep" <teastep@shorewall.net> To: "Clint Miller" <cmiller@tigerbyte.com> Cc: "Shorewall Users" <shorewall-users@lists.shorewall.net> Sent: Thursday, December 11, 2003 4:57 AM Subject: Re: [Shorewall-users] Large number of SNAT''d addresses loads veryslowly> On Wednesday 10 December 2003 02:16 pm, you wrote: > > Tom - > > > > On Wednesday 10 December 2003 15:14, Tom Eastep wrote: > > > I''m saying to do that WITHOUT ADDING THE ADDRESSES to the tunnel > > > interface! I don''t believe that they serve any purpose. > > > > > > -Tom > > > > I''ve tried without adding the addresses. It doesn''t work. The routetable> > ends up looking something like this on our central VPN server: > > > > > > Routes and aliases have *nothing* to do with one another: > > a) Leave the routing the way it is. > b) Leave all NAT the way it is. > c) Just don''t add the 100s of extra addresses to the tun* interface. > > -Tom > -- > Tom Eastep \ Nothing is foolproof to a sufficiently talented fool > Shoreline, \ http://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 >