search for: martians

I noticed I got a strange connection from what seems to be a user in italy?!? and he connected to my SMB client maybe?? I'm assuming the errors in his logfile ( http://68.48.247.187/log.gustavo.txt ) not finding the service.c file are because he is being denied access.. but how is he connecting in the first place.. And why isnt he being refused by my servers hosts.deny file...? I have

Hi all: I see a lot of the errors below in /var/log/messages on my firewall: Aug 1 00:47:44 munin kernel: [109008.257109] martian source 192.168.1.5 from 127.0.0.1, on dev eth1 Aug 1 00:48:44 munin kernel: [109068.257384] martian source 192.168.1.5 from 127.0.0.1, on dev eth1 Aug 1 00:49:44 munin kernel: [109128.257509] martian source 192.168.1.5 from 127.0.0.1, on dev eth1 Aug 1 00:50:44

...dress eventually it will report the interface that the traffic is being received on -- that would be the balancing feature of the multiple paths. I believe that during these times when ip route get is reporting the alternate interface, the kernel would also log inbound packets from that address as martians. Is this the case? To further confirm my supposition, while my gateway is dropping packets and logging them as martians, I can install a route specifically for that source pointing to the interface that they are being received on and the dropping/martian logging stops and the traffic is received....

...oesn''t like? I have this rule to allow UDP port 123: ACCEPT sls fw udp 123 - A portion of my shorewall show status is below (the full output is in a previous message re: AllowPing). There are no hits for UDP 123 coming from 10.0.0.x, probably because they are seen as martians. Chain sls2fw (1 references) pkts bytes target prot opt in out source destination 108 5362 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 1 44 @all2all tcp -- * * 0.0.0.0/0...

[ sorry for cross-posting this to newbies and users, but I''m a bit desperate to get this resolved ] This is strange... I had this working before without any problems, and recently we started to have some odd issues. I can''t be sure exactly what has changed as I''m unfortunately not the only person with access to the server. {sigh} The problem is that I pretty much

Guys, good afternoon I'm using in my bond interfaces as active backup, in theory, should assume an interface (or work) only when another interface is down. But I'm just lost packets on the interface that is not being used and is generating packet loss on bond. What can that be? Follow my settings bond [root at xxxxx ~]# ifconfig bond0 ; ifconfig eth0 ; ifconfig eth1 bond0

I''m playing around with VLAN''s and I have a VLAN capable (layer 2) smart switch. I see a steady stream of martians in the logfile if I have the routefilter option set on the loc zone interfaces in /etc/shorewall/interfaces. I have two interfaces in the loc zone, eth1 and vlan2 respectively. vlan2 is an 802.1q trunk going towards the switch. Is this the expected behavior in this configuration? I just want to...

...an communicate from the server to the vpn endpoints just fine from the server, but not from other devices on the network very well because the router (and other devices) cannot get the arp to resolve for 172.28.130.6. I looked at wireshark to verify that it is APR requests that are ending up as martians. I have tried various combination''s in the interface file but nothing helps. Here is what I have it at at the moment: ipsec ipsec+ detect pptp ppp+ detect admin eth4 detect proxyarp,arp_filter chart eth3 detect norfc1918,routefilter,arp_ignore,nosmurfs tds...

Hi All, As you probably all know :-) I''m trying to do the multi-isp thing. I''ve resolved my last issue with the route_rules as suggested by Tom and Jerry suggested. Lately I have been seeing "transient" (I say transient because the problem will persist for a while and then magically clear itself up some number of minutes later) situations where my gateway will log:

...S2: ABC.DEF.254.101 ABC.DEF.254.101 ABC.DEF.254.101 NS3: ABD.XYZ.254.100 ABD.XYZ.254.100 ABD.XYZ.254.100 /etc/shorewall/zones fw firewall net ipv4 loc ipv4 serv ipv4 /etc/shorewall/interfaces net eth0 detect proxyarp,tcpflags,routefilter,nosmurfs,logmartians,norfc1918 serv eth1 detect dhcp loc eth2 detect dhcp,tcpflags,nosmurfs,blacklist (no masq file, no proxyarp file) This is also the setup for a firewall for the same local network (Shorewall 1.0.3) which works for several years. I just want to replace the older PC with a newer one ... I have...

I''ve set up a simple 2-interface Linux router using shorewall-perl 4.0.8 (and upgraded to 4.0.9). Everything works flawlessly. One small exception I have noticed (since I''m a new shorewall user I assume this is probably an error on my part). 1. Problem: With no "logmartians" entries in /etc/shorewall/interfaces, shorewall-perl sets /proc/sys/net/ipv4/conf/*/log_martians to "0". 2. Expected behavior: For any interface entry in /etc/shorewall/interfaces for which the "logmartians" option is not present, shorewall-perl should take no action, lea...

Hi I''m trying to monitor my multi ISP shorewall with swping, the script works fine, i can see in log when an ISP is down, the script restart shorewall and /etc/shorewall/isusable is called, however in the swping log after the shorewall restart i see again a route by ISP (even the ISP down), is it normal ? should i not see one route less? shorewall version 4.4.5.4-1. ****

the establishment of an openvpn link sometimes fails. I tracked it down to network traffic with wrong Sourceport in the answer packet (should be 1300 not 1024): 2 1.119309000 aaa.185.165 bbb.162.192 UDP 58 Source port: 1300 Destination port: 1300 3 1.119446000 bbb.162.192 aaa.185.165 UDP 66 Source port: 1024 Destination port: 1300 and a collateral entry in the connection tracking table

I have posted this question to the netfilter mailing list along with #ebtables, #iptables, and #netfilter. Nobody has really responded, so I''m led to believe that it is either incredibly complicated or *really* simple. Please, somebody throw me a bone here! Ok, on with the show... I have a bridge (br0) with two interfaces (eth1 and eth2). Neither br0, eth1, or eth2 have an

...tions now invoke the new standard action ''AllowICMPs''. This new action accepts critical ICMP types: Type 3 code 4 (fragmentation needed) Type 11 (TTL exceeded) 2) Explicit control over the kernel''s Martian logging is now provided using the new ''logmartians'' interface option. If you include ''logmartians'' in the interface option list then logging of Martian packets on will be enabled on the specified interface. If you wish to globally enable martian logging, you can set MARTIAN_LOGGING=Yes in shorewall.conf. 3) Y...

...57 firewall kernel: [ 895.708399] ll header: ff:ff:ff:ff:ff:ff:90:f6:52:3f:65:c0:08:00 Nov 8 15:37:59 firewall kernel: [ 897.711647] martian source 192.168.0.3 from 192.168.0.1, on dev eth0 Nov 8 15:37:59 firewall kernel: [ 897.711654] ll header: ff:ff:ff:ff:ff:ff:90:f6:52:3f:65:c0:08:00 LOG_MARTIANS= (Yes|No) no matter if above variable is yes or no, logs are keep coming. echo "0" > /proc/sys/net/ipv4/conf/eth0/rp_filter when i change the value 1 to 0, and restart the shorewall by using the command "shorewall restart" it automatically change the value from 0 to 1. ca...

...|INVALID --- Comment #1 from Phil Oester <netfilter at linuxace.com> 2013-06-14 17:01:31 CEST --- These packets will never make it to netfilter, because they will be dropped by the network core as a martian source. If you enable logging of martian packets (via /proc/sys/net/ipv4/conf/*/log_martians), you will see an entry in your syslog similar to this: localhost kernel: [19202.736982] IPv4: martian source 192.168.19.150 from 192.168.19.255, on dev p3p1 As such, this is not a netfilter bug - it is simply the way Linux works. Closing. -- Configure bugmail: https://bugzilla.netfilter.org/u...

I have been working really hard configuring and researching very extensively, trying to figure why we are getting "Shorewall:FORWARD:DROP" packets. IPSEC works just fine without the iptable rules created by our shorewall configs but when starting shorewall and creating the iptables I noticed the packets are dropped. I know it is a config situation but I am totally racking my brain as

Hi, I have recently installed shorewall with a very simple rules configuration, ---------------------------------- #SECTION RELATED SECTION NEW Ping/ACCEPT all $FW Trcrt/ACCEPT all $FW SSH/ACCEPT all $FW ACCEPT net $FW tcp http #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE ----------------------------------------- and I have no

The man page isn't helping, nor have I been able to find examples that work. For example, the man page claims I can do ipmitool lan get active, and I try, and it says, "invaling lan command, get". Do I set the MAC address for the lan to NIC 2? Anyone have a clue - I do *not* want martians on the real network. mark