Hello, I''m having some very odd problems with dnat, and after digging for quite some time I can''t come up with an answer. As requested on the support page, I will be sending a shorewall dump to support@shorewall.net. It probably makes it tougher, but I prefer not to post my filter configs for the world. The problem is as follows: I have multiple zones, each with a single interface. Two are internet-facing. I am dnatting from one of those to a zone "loc." I have a rule that says dnat from all zones to loc:10.24.101.103 when the original destination is 69.129.249.241 (a public IP of mine in the tds01 zone) udp port 2301. The rule works as expected for traffic arriving on all interfaces except the tds01 zone (the public facing zone with the dnat IP). tcpdump shows the traffic coming in on tds01, and nothing going out on the loc zone. The counter for the rule in tds01_dnat is incremented, and the associated rule in tds012loc does not get incremented. It sounds like a routing issue, but the routing tables are correct, and traffic can pass through each of them to 10.24.101.103 and out the right interface (eth7 a.k.a. "loc"). The accompanying dump was performed after clearing the counters and attempting connections from the zones $FW (this originates as 69.129.249.241 when trying the dnat), ndev (10.99.55.146), mnet (10.24.99.250), loc itself (10.24.101.103 - just making sure it didn''t work like normal) and tds01 (64.73.12.253). As I said, the only traffic that doesn''t work is traffic from the internet (tds01). I have noticed that the connections coming in via tds01 are never going into connection tracking even though the dnat rule is hit. dropInvalid doesn''t seem to be where the traffic disappears based on watching the dropInvalid counter and sending packets from the internet to the dnat address. I have many dnat rules to zones which aren''t "loc" (including rules on the same public IP), all of which work correctly. I have tried a dnat from tds02 -> loc:10.24.101.103 and that works fine. I''ve tried other IPs on tds01 -> loc and that fails. It seems to be only tds01 -> loc (dnat) traffic which disappears. I realize this may not be the best problem description. It will be difficult to understand without the dump; I''m not sure where the support@shorewall.net address goes. Ask questions if I wasn''t clear enough. Many thanks in advance. -Brad ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php
Brad wrote: fic which disappears.> > I realize this may not be the best problem description. It will be difficult to > understand without the dump; I''m not sure where the support@shorewall.net > address goes. Ask questions if I wasn''t clear enough.What IP address are you trying to connect FROM? -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 ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php
Tom Eastep wrote:> Brad wrote: > fic which disappears. >> >> I realize this may not be the best problem description. It will be >> difficult to >> understand without the dump; I''m not sure where the support@shorewall.net >> address goes. Ask questions if I wasn''t clear enough. > > What IP address are you trying to connect FROM?I re-read your post and I _think_ it says that when connecting from tds01, your host IP is 64.73.12.253. If that is the case, the packets are being dropped as Martians. I don''t understand what you are trying to accomplish with your very unusual routing configuration but given that you don''t specify ''balance'' on your providers, you MUST turn off route filtering (your current setup is very unwise -- you have route filtering enabled on all interfaces but have logmartians disabled!!). -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 ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php
On Sat, 7 Jun 2008, Tom Eastep wrote:> I re-read your post and I _think_ it says that when connecting from tds01, > your host IP is 64.73.12.253. If that is the case, the packets are being > dropped as Martians.Yes, that is the internet address I connected from. Good catch on LOGMARTIANS being off, that is normally turned on in my shorewall configs. However, the packets shouldn''t be logged martians...there are 3 routing tables: main, tds01, and tds02. tds01 defines the default gateway out eth1 (tds01). I turned on martian logging to confirm, and nothing is logged as a martian when testing the connection again. I also have other DNAT rules specified coming in tds01 (to the same IP even), and those work fine.> I don''t understand what you are trying to accomplish with your very unusual > routing configuration but given that you don''t specify ''balance'' on your > providers, you MUST turn off route filtering (your current setup is very > unwise -- you have route filtering enabled on all interfaces but have > logmartians disabled!!).I''m not using ''balance'' because I want to route specific traffic out specific interfaces...note the ip rules in the dump. Thanks, -Brad ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php
Brad wrote:> On Sat, 7 Jun 2008, Tom Eastep wrote: > >> I re-read your post and I _think_ it says that when connecting from tds01, >> your host IP is 64.73.12.253. If that is the case, the packets are being >> dropped as Martians. > > Yes, that is the internet address I connected from. Good catch on LOGMARTIANS > being off, that is normally turned on in my shorewall configs. However, the > packets shouldn''t be logged martians...there are 3 routing tables: main, tds01, > and tds02. tds01 defines the default gateway out eth1 (tds01)I can see that. But only the main table is involved in route filtering.> I turned on > martian logging to confirm, and nothing is logged as a martian when testing the > connection again. I also have other DNAT rules specified coming in tds01 (to > the same IP even), and those work fine.Then I have no idea what the problem is.> > I''m not using ''balance'' because I want to route specific traffic out specific > interfaces...note the ip rules in the dump. >See FAQs 57 and 58. The ''balance'' option is not incompatible with what you want to do. -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 ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php
Tom Eastep wrote:> > I can see that. But only the main table is involved in route filtering. > >> I turned on >> martian logging to confirm, and nothing is logged as a martian when >> testing the >> connection again. I also have other DNAT rules specified coming in >> tds01 (to >> the same IP even), and those work fine. > > Then I have no idea what the problem is.But I would still try turning off route filtering. Because that is the only cause that I know of that can drop a packet between the nat PREROUTING chain and the filter FORWARD chain. -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 ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php
Thanks...after thinking about routefilter, I don''t know why I ever added it to the public interfaces. I would be much better served replacing routefilter with norfc1918 there.> > I can see that. But only the main table is involved in route filtering.That''s correct...I realized that before, but I never took into consideration route filtering because a) I didn''t get any logs (my mistake as you saw!) and b) I''ve had the other dnat rules in place on tds01 for weeks now with no problems. But, turning off routefilter did get the dnat functioning. I''ve no clue why I didn''t have problems with any other rules. I''ll have to ponder that one. So far, I think it must be a difference between ndev/mnet and loc as the rules to ndev and mnet always worked and loc never did. I''m also curious why after turning on LOGMARTIANS I didn''t see any logs.> See FAQs 57 and 58. The ''balance'' option is not incompatible with what you > want to do.I suppose I should have specified that I''m not using shorewall providers. I do plan in the future to create a balance table and use tc, whether that will be shorewall controlled or not, but that''s a project for another day. I used shorewall for that in the past, and it worked very nicely. Thanks for your time Tom, and thanks for all the time you''ve saved me over the years writing iptables rules by hand. :) -Brad ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php
Brad wrote:> > Thanks for your time Tom, and thanks for all the time you''ve saved me over the > years writing iptables rules by hand. :) >You''re most welcome, Brad. -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 ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php