In the past month or so, I have been getting a flood of martian packets showing in my syslog. According to the log, the martian source is always one server, but the ''from'' IP will be anything within the range of my blocks from either ISP, including the .255 broadcast. I do not get any martian logs for any other server. Specifics... - Firewall is Ubuntu, kernel is 2.6.31-22-generic, shorewall is 4.2.10 - ISP1 is on eth0, ISP2 is on eth4, All servers are on DMZ, eth1. There is no switch or bridge between the interfaces except for shorewall. - The options for both ISPs specified in the interfaces file are "norfc1918,tcpflags,logmartians,nosmurfs,optional" The server stated in the logs has only two services running on it, and traffic appears to be flowing normally. I have compared my entries in rules and masq between entries for the other servers, and the entries for this server, and can find no problems. I have asked for help on freenode, but have not been able to solve the problem. Any further help would be much appreciated. As per requested, I have a couple of text files with information... http://sourpuss.net/temp/shorewall.log -- clippings from the log file of martian packets http://sourpuss.net/temp/shorewall.dump -- results from the ''shorewall dump'' command There are three servers on the DMZ that handle similar traffic: 1 - responds on 10.0.0.1/10.0.0.201/10.0.0.209 2 - responds on 10.0.0.2/10.0.0.205/10.0.0.214 3 - responds on 10.0.0.9/10.0.0.203/10.0.0.211 (this is the one spawning the martian logs) (The multiple IP''s are potentially for future packet marking to keep outbound traffic on the same ISP it came in from) ------------------------------------------------------------------------------ ThinkGeek and WIRED''s GeekDad team up for the Ultimate GeekDad Father''s Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo
On Wed, 2010-06-16 at 23:41 -0600, Jeff Taylor wrote:> In the past month or so, I have been getting a flood of martian packets > showing in my syslog. According to the log, the martian source is > always one server, but the ''from'' IP will be anything within the range > of my blocks from either ISP, including the .255 broadcast. I do not > get any martian logs for any other server. > > Specifics... > - Firewall is Ubuntu, kernel is 2.6.31-22-generic, shorewall is 4.2.10 > - ISP1 is on eth0, ISP2 is on eth4, All servers are on DMZ, eth1. There > is no switch or bridge between the interfaces except for shorewall. > - The options for both ISPs specified in the interfaces file are > "norfc1918,tcpflags,logmartians,nosmurfs,optional" > > The server stated in the logs has only two services running on it, and > traffic appears to be flowing normally. I have compared my entries in > rules and masq between entries for the other servers, and the entries > for this server, and can find no problems. I have asked for help on > freenode, but have not been able to solve the problem. Any further help > would be much appreciated. > > As per requested, I have a couple of text files with information... > http://sourpuss.net/temp/shorewall.log -- clippings from the log file of > martian packets > http://sourpuss.net/temp/shorewall.dump -- results from the ''shorewall > dump'' command > > There are three servers on the DMZ that handle similar traffic: > 1 - responds on 10.0.0.1/10.0.0.201/10.0.0.209 > 2 - responds on 10.0.0.2/10.0.0.205/10.0.0.214 > 3 - responds on 10.0.0.9/10.0.0.203/10.0.0.211 (this is the one spawning > the martian logs) > (The multiple IP''s are potentially for future packet marking to keep > outbound traffic on the same ISP it came in from)Try moving that MASQ rule to be after all the SNAT rules. First match wins and the SNAT rules after that MASQ rule will not be used. Hope that is your fix, Jerry ------------------------------------------------------------------------------ ThinkGeek and WIRED''s GeekDad team up for the Ultimate GeekDad Father''s Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo
I assume you''re referring to this portion? 25801 1979K MASQUERADE all -- * * 10.0.0.0/16 0.0.0.0/0 2212 112K SNAT all -- * * 10.10.0.0/16 0.0.0.0/0 to:216.87.84.211 39 2340 SNAT all -- * * 10.20.0.0/16 0.0.0.0/0 to:216.87.84.212 I made the change, but it had no effect. I pasted a new ''shorewall dump'' at the same location. Any other thoughts? Jerry Vonau wrote:> Try moving that MASQ rule to be after all the SNAT rules. First match > wins and the SNAT rules after that MASQ rule will not be used. > > Hope that is your fix, > > Jerry > >------------------------------------------------------------------------------ ThinkGeek and WIRED''s GeekDad team up for the Ultimate GeekDad Father''s Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo
On Thu, 2010-06-17 at 10:35 -0600, Jeff Taylor wrote:> I assume you''re referring to this portion? > > 25801 1979K MASQUERADE all -- * * 10.0.0.0/16 0.0.0.0/0 > 2212 112K SNAT all -- * * 10.10.0.0/16 0.0.0.0/0 to:216.87.84.211 > 39 2340 SNAT all -- * * 10.20.0.0/16 0.0.0.0/0 to:216.87.84.212 > > > I made the change, but it had no effect. I pasted a new ''shorewall > dump'' at the same location. Any other thoughts? >well.. Chain DSL_dnat (1 references) 2502K 170M DNAT udp -- * * 0.0.0.0/0 216.87.84.211 udp dpt:53 to:10.0.0.211 478 25240 DNAT tcp -- * * 0.0.0.0/0 216.87.84.211 tcp dpt:53 to:10.0.0.211 OK, you have the inbound dnat''d on a secondary address Chain eth0_masq (1 references) 683K 52M SNAT udp -- * * 10.0.0.9 0.0.0.0/0 udp dpt:53 to:216.87.84.211 547 32820 SNAT tcp -- * * 10.0.0.9 0.0.0.0/0 tcp dpt:53 to:216.87.84.211 The return traffic from 10.0.0.9, that was redirected at the firewall, would have a source port of 53 coming from 10.0.0.9, no? Then wouldn''t that be: 683K 52M SNAT udp -- * * 10.0.0.9 0.0.0.0/0 udp spt:53 to:216.87.84.211 547 32820 SNAT tcp -- * * 10.0.0.9 0.0.0.0/0 tcp spt:53 to:216.87.84.211 or then the next rule gets applied 25801 1979K MASQUERADE all -- * * 10.0.0.0/16 0.0.0.0/0 which would select 216.87.84.210 as the source address as the primary address on that interface. I''d like to help more now, but I require some sleep, up in ~6 hours. Jerry ------------------------------------------------------------------------------ ThinkGeek and WIRED''s GeekDad team up for the Ultimate GeekDad Father''s Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo
On 6/17/10 9:35 AM, Jeff Taylor wrote:> I assume you''re referring to this portion? > > 25801 1979K MASQUERADE all -- * * 10.0.0.0/16 0.0.0.0/0 > 2212 112K SNAT all -- * * 10.10.0.0/16 0.0.0.0/0 to:216.87.84.211 > 39 2340 SNAT all -- * * 10.20.0.0/16 0.0.0.0/0 to:216.87.84.212 >If you ''tcpdump -nei eth0 host 10.0.0.211'', do you see any traffic? Similarly ''tcpdump -nei eth4 host 10.0.0.203''? -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ ThinkGeek and WIRED''s GeekDad team up for the Ultimate GeekDad Father''s Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo
I''ve been running both commands for about an hour, and have NOT seen any results from the tcdump commands on either nic. Martian logs are continuing as normal. Tom Eastep wrote:> On 6/17/10 9:35 AM, Jeff Taylor wrote: > >> I assume you''re referring to this portion? >> >> 25801 1979K MASQUERADE all -- * * 10.0.0.0/16 0.0.0.0/0 >> 2212 112K SNAT all -- * * 10.10.0.0/16 0.0.0.0/0 to:216.87.84.211 >> 39 2340 SNAT all -- * * 10.20.0.0/16 0.0.0.0/0 to:216.87.84.212 >> >> > > > If you ''tcpdump -nei eth0 host 10.0.0.211'', do you see any traffic? > > Similarly ''tcpdump -nei eth4 host 10.0.0.203''? > > -Tom > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > ThinkGeek and WIRED''s GeekDad team up for the Ultimate > GeekDad Father''s Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > ------------------------------------------------------------------------ > > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users >------------------------------------------------------------------------------ ThinkGeek and WIRED''s GeekDad team up for the Ultimate GeekDad Father''s Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo
On 6/17/10 8:50 PM, Jeff Taylor wrote:> I''ve been running both commands for about an hour, and have NOT seen any > results from the tcdump commands on either nic. Martian logs are > continuing as normal.Okay, so the martians have undergone NAT prior to routing and have had their destination address rewritten to 10.0.0.xxx (it is in the routing step that reverse path filtering is done). The fascinating thing about the martians is that their source IP address is always one of the firewall''s own addresses. It''s a real mystery how such packets are arriving from outside the firewall. The only odd thing that I see in the dump is in the main routing table: Table main: 216.87.95.1 via 216.87.84.208 dev eth0 216.87.84.192/27 dev eth0 proto kernel scope link src 216.87.84.210 173.160.58.0/24 dev eth4 proto kernel scope link src 173.160.58.202 10.0.0.0/16 dev eth1 proto kernel scope link src 10.0.0.254 10.20.0.0/16 dev eth3 proto kernel scope link src 10.20.0.254 10.10.0.0/16 dev eth2 proto kernel scope link src 10.10.0.254 10.250.0.0/16 dev eth5 proto kernel scope link src 10.250.0.254 default nexthop via 216.87.84.208 dev eth0 weight 1 nexthop via 173.160.58.206 dev eth4 weight 2 default via 173.160.58.206 dev eth4 src 173.160.58.205 metric 100 default via 173.160.58.206 dev eth4 src 173.160.58.204 metric 100 default via 173.160.58.206 dev eth4 src 173.160.58.203 metric 100 default via 173.160.58.206 dev eth4 src 173.160.58.201 metric 100 default via 216.87.84.208 dev eth0 src 216.87.84.214 metric 100 default via 216.87.84.208 dev eth0 src 216.87.84.212 metric 100 default via 216.87.84.208 dev eth0 src 216.87.84.211 metric 100 default via 216.87.84.208 dev eth0 src 216.87.84.209 metric 100 default via 173.160.58.206 dev eth4 metric 100 default via 216.87.84.208 dev eth0 metric 100 Note all of the silly default routes with metric 100. It appears that you have included a ''default'' specification in /etc/network/interfaces as part of the stanza of each secondary IP address. I wouldn''t think that would cause what you are seeing though. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ ThinkGeek and WIRED''s GeekDad team up for the Ultimate GeekDad Father''s Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo
All of my secondary interfaces (to recognize the full block of IPs) are defined like this... auto eth0:209 iface eth0:209 inet static address 216.87.84.209 netmask 255.255.255.224 broadcast 216.87.84.255 network 216.87.84.0 gateway 216.87.84.208 However I''ve noticed the large number of default routes present when I do a route command, but never thought anything of it. As I said before, the thing that really puzzles me is that the setup for routing packets to the other servers in the DMZ appears to be identical, so I don''t understand why this is the only server that seems to be affected. One more curious bit to add to the mix... I currently have only port 53 defined to route to 10.0.0.203/211. There is no other mention in shorewall of these IPs. And yet if I stop BIND on that server, I am still seeing the martian logs. If I change the IP in shorewall to 10.0.0.9, the martian logs immediately follow the change. If I can''t get this figured out soon, I may go ahead and set up shorewall on each of my DMZ servers, then I can just have the firewall directly route ALL traffic from specific IP''s over to specific servers, and let the server figure out it''s own traffic. If nothing else, it would probably help reduce the amount of processing the firewall needs to do. Tom Eastep wrote:> On 6/17/10 8:50 PM, Jeff Taylor wrote: > >> I''ve been running both commands for about an hour, and have NOT seen any >> results from the tcdump commands on either nic. Martian logs are >> continuing as normal. >> > > Okay, so the martians have undergone NAT prior to routing and have had > their destination address rewritten to 10.0.0.xxx (it is in the routing > step that reverse path filtering is done). The fascinating thing about > the martians is that their source IP address is always one of the > firewall''s own addresses. It''s a real mystery how such packets are > arriving from outside the firewall. > > The only odd thing that I see in the dump is in the main routing table: > > Table main: > > 216.87.95.1 via 216.87.84.208 dev eth0 > 216.87.84.192/27 dev eth0 proto kernel scope link src 216.87.84.210 > 173.160.58.0/24 dev eth4 proto kernel scope link src 173.160.58.202 > 10.0.0.0/16 dev eth1 proto kernel scope link src 10.0.0.254 > 10.20.0.0/16 dev eth3 proto kernel scope link src 10.20.0.254 > 10.10.0.0/16 dev eth2 proto kernel scope link src 10.10.0.254 > 10.250.0.0/16 dev eth5 proto kernel scope link src 10.250.0.254 > default > nexthop via 216.87.84.208 dev eth0 weight 1 > nexthop via 173.160.58.206 dev eth4 weight 2 > default via 173.160.58.206 dev eth4 src 173.160.58.205 metric 100 > default via 173.160.58.206 dev eth4 src 173.160.58.204 metric 100 > default via 173.160.58.206 dev eth4 src 173.160.58.203 metric 100 > default via 173.160.58.206 dev eth4 src 173.160.58.201 metric 100 > default via 216.87.84.208 dev eth0 src 216.87.84.214 metric 100 > default via 216.87.84.208 dev eth0 src 216.87.84.212 metric 100 > default via 216.87.84.208 dev eth0 src 216.87.84.211 metric 100 > default via 216.87.84.208 dev eth0 src 216.87.84.209 metric 100 > default via 173.160.58.206 dev eth4 metric 100 > default via 216.87.84.208 dev eth0 metric 100 > > Note all of the silly default routes with metric 100. It appears that > you have included a ''default'' specification in /etc/network/interfaces > as part of the stanza of each secondary IP address. I wouldn''t think > that would cause what you are seeing though. > > -Tom >------------------------------------------------------------------------------ ThinkGeek and WIRED''s GeekDad team up for the Ultimate GeekDad Father''s Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo