lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 30 Nov 2011 23:46:02 -0600
From:	"Greg Scott" <GregScott@...rasupport.com>
To:	"Michal Soltys" <soltys@....info>,
	"David Lamparter" <equinox@...c24.net>
Cc:	<netdev@...r.kernel.org>
Subject: RE: ebtables on a stick

Well this is frustrating.  Now my public host can communicate anywhere it wants internally but nothing outside. Maddening - the exact opposite problem I had before.  

Here is the config as it sits right now:

Public IP host (a Windows XP system placeholder for now)
IP 1.2.115.157, default gw 1.2.115.146.

My test internal host - 192.168.10.2.  This one is an ordinary Windows server.

Firewall eth0 - 1.2.115.146/28
Firewall eth1 - 192.168.10.1. 

/sbin/ip neigh add proxy 1.2.115.157 dev eth0
/sbin/ip route add 1.2.115.157/32 dev eth1

As a troubleshooting step, I also put in:
/sbin/ip addr add 1.2.115.146/28 dev eth1; so now both eth0 and eth1 have the same IP Address.  This feels ugly and I think I'll take it out because it made no difference.  

All evidence of ebtables rules and brnn interfaces are gone.  

And the relevant iptables rules:

$IPTABLES -t nat -A POSTROUTING -s $1.2.115.157 -j ACCEPT

$IPTABLES -A FORWARD -s 1.2.115.157 -j ACCEPT
$IPTABLES -A FORWARD -s 192.168.10.0/24 -d 1.2.115.157 -j ACCEPT
$IPTABLES -A FORWARD -p TCP --dport 1720 -d $ADR -j allowed
$IPTABLES -A FORWARD -p TCP -s $MGMT_IP -d $ADR -j allowed

$MGMT_IP is the public side of my home office.  

And finally:

$IPTABLES -t nat -A PREROUTING -d 1.2.115.157 -j ACCEPT

When my public host pings, say, google, watching on the firewall with tcpdump, I see the ICMP echo request come in on eth1 and go out eth0.  So far so good. The ICMP echo reply comes back on eth0, still good.  But I never forward it over to eth1 and it dies right there.  The public host never sees the reply. 

Nothing nats to/from this address.  Tcpdump shows the IP Addresses I expect to see.  And I don't have any "-t raw -j NOTRACK" stuff because I will eventually want to use the H.323 conntrack helper with this.  

Maybe a good night's sleep will help.

- Greg

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ