Thank you, Charles, et al. for your continued participation . . .
Charles Steinkuehler wrote:
>
> > root@bluetrout:/root
> > # ip addr
> > . . .
> > 7: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
> > link/ether 00:a0:c9:9e:57:70 brd ff:ff:ff:ff:ff:ff
> > inet 192.168.1.254/24 brd 192.168.1.255 scope global eth0
> > 8: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
> > link/ether 00:a0:c9:9e:64:83 brd ff:ff:ff:ff:ff:ff
> > inet 64.4.197.65/26 brd 64.4.197.127 scope global eth1
> > 11: wan1: <POINTOPOINT,NOARP,UP> mtu 1500 qdisc pfifo_fast qlen 100
> > link/ppp
> > inet 64.4.222.157 peer 64.4.222.158/32 scope global wan1
> > inet 64.4.197.99/32 scope global wan1
> > inet 64.4.197.100/32 scope global wan1
> > inet 64.4.197.101/32 scope global wan1
>
> OK, now I'm officially confused. You indicate you're running a
> proxy-arp DMZ, but your external interface isn't ARP capable. I at
> least need to see your full routing table, and I'm not sure you can
> setup your DMZ with proxy-arp or routing and maintain full connectivity
> to the internet (as things stand now, I think you'll at least be loosing
> access to the network IP and broadcast IP used on the DMZ network),
> which look like they could be valid IP's (although neither responded to
> pings or http reqests).
Yes, I, too, have been confused by some of this. We have several
successful proxy-arp dmz's; so, when we built this one, we started by
cloning those other config's and changing addresses, &c. and it appeared
to be working as expected.
# ip route
64.4.222.158 dev ipsec0 proto kernel scope link src 64.4.222.157
64.4.222.158 dev wan1 proto kernel scope link src 64.4.222.157
64.4.197.64/26 dev eth1 scope link
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.254
192.168.123.0/24 via 64.4.222.158 dev ipsec0
default via 64.4.222.158 dev wan1
I, too, have been confused by this errant ping-ability of 64.4.197.64 &
64.4.197.127.
> Any details of how your ISP is piping the extra IP's to you would also
> be helpful. They're obviously not routing a subnet to your external WAN
> IP, which would be more typical, and I'm not familiar enough with ppp
> interfaces to know if the kernel will recieve packets sent to alternate
> IP's if the IP isn't configured on that interface (although I'd think it
> would).
I cannot say for certain; but, this may prove enlightening to somebody
who knows more than me:
<http://www.helices.org/tmP/wanpipe.bluetrout.txt>
> Given the above IP configuation, and the firewall rules you posted, I
> would think a static-NAT or possibly standard routed DMZ would be more
> appropriate than Proxy-Arp, but apparently things are working as-is (can
> you verify current functionality of the DMZ? Does everything but DNS
> resolution work properly?).
As stated above, proxy-arp dmz was accidental; but, appeared to be
working -- to all other extents.
Today, I reconfigured it as:
wan1_PROXY_ARP=NO
eth0_PROXY_ARP=NO
eth1_PROXY_ARP=NO
DMZ_SWITCH=YES
DMZ_IF="eth1"
DMZ_NET=64.4.197.64/26
DMZ_SRC=""
DMZ_HIGH_TCP_CONNECT=NO
DMZ_OUTBOUND_ALL=YES
Resulting rules are here:
<http://www.helices.org/tmP/ipchains.no_proxy_arp.bluetrout.txt>
# ip route
64.4.222.158 dev ipsec0 proto kernel scope link src 64.4.222.157
64.4.222.158 dev wan1 proto kernel scope link src 64.4.222.157
64.4.197.64/26 dev eth1 proto kernel scope link src 64.4.197.65
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.254
192.168.123.0/24 via 64.4.222.158 dev ipsec0
default via 64.4.222.158 dev wan1
root@bluetrout:/tmp
# ip addr
. . .
7: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
link/ether 00:a0:c9:9e:57:70 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.254/24 brd 192.168.1.255 scope global eth0
8: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
link/ether 00:a0:c9:9e:64:83 brd ff:ff:ff:ff:ff:ff
inet 64.4.197.65/26 brd 64.4.197.127 scope global eth1
17: wan1: <POINTOPOINT,NOARP,UP> mtu 1500 qdisc pfifo_fast qlen 100
link/ppp
inet 64.4.222.157 peer 64.4.222.158/32 scope global wan1
inet 64.4.197.99/32 scope global wan1
inet 64.4.197.100/32 scope global wan1
inet 64.4.197.101/32 scope global wan1
Nevertheless, 64.4.197.64 & 64.4.197.127 remain un-ping-able from the
internet. From this network, ping-ability remains static and curious:
[ dcd ]
root@bluetrout:/tmp
# ping -c 3 64.4.197.64
PING 64.4.197.64 (64.4.197.64): 56 data bytes
64 bytes from 64.4.197.65: icmp_seq=0 ttl=255 time=0.3 ms
64 bytes from 64.4.197.69: icmp_seq=0 ttl=255 time=0.7 ms (DUP!)
64 bytes from 64.4.197.68: icmp_seq=0 ttl=128 time=0.9 ms (DUP!)
64 bytes from 64.4.197.65: icmp_seq=1 ttl=255 time=0.3 ms
64 bytes from 64.4.197.69: icmp_seq=1 ttl=255 time=0.6 ms (DUP!)
64 bytes from 64.4.197.68: icmp_seq=1 ttl=128 time=0.9 ms (DUP!)
64 bytes from 64.4.197.65: icmp_seq=2 ttl=255 time=0.3 ms
--- 64.4.197.64 ping statistics ---
3 packets transmitted, 3 packets received, 4 duplicates, 0% packet loss
round-trip min/avg/max = 0.3/0.5/0.9 ms
root@bluetrout:/tmp
# ping -c 3 64.4.197.127
PING 64.4.197.127 (64.4.197.127): 56 data bytes
64 bytes from 64.4.197.65: icmp_seq=0 ttl=255 time=0.3 ms
64 bytes from 64.4.197.69: icmp_seq=0 ttl=255 time=0.7 ms (DUP!)
64 bytes from 64.4.197.68: icmp_seq=0 ttl=128 time=0.9 ms (DUP!)
64 bytes from 64.4.197.65: icmp_seq=1 ttl=255 time=0.3 ms
64 bytes from 64.4.197.69: icmp_seq=1 ttl=255 time=0.7 ms (DUP!)
64 bytes from 64.4.197.68: icmp_seq=1 ttl=128 time=0.9 ms (DUP!)
64 bytes from 64.4.197.65: icmp_seq=2 ttl=255 time=0.3 ms
--- 64.4.197.127 ping statistics ---
3 packets transmitted, 3 packets received, 4 duplicates, 0% packet loss
round-trip min/avg/max = 0.3/0.5/0.9 ms
[ internal network ]
root@Bob:~
# ping -c 3 64.4.197.64
PING 64.4.197.64 (64.4.197.64): 56 data bytes
64 bytes from 192.168.1.254: icmp_seq=0 ttl=255 time=0.3 ms
64 bytes from 192.168.1.254: icmp_seq=1 ttl=255 time=0.2 ms
64 bytes from 192.168.1.254: icmp_seq=2 ttl=255 time=0.2 ms
--- 64.4.197.64 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.2/0.2/0.3 ms
# ping -c 3 64.4.197.127
PING 64.4.197.127 (64.4.197.127): 56 data bytes
64 bytes from 192.168.1.254: icmp_seq=0 ttl=255 time=0.3 ms
64 bytes from 192.168.1.254: icmp_seq=1 ttl=255 time=0.2 ms
64 bytes from 192.168.1.254: icmp_seq=2 ttl=255 time=0.2 ms
--- 64.4.197.127 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.2/0.2/0.3 ms
# ip addr
. . .
3: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
link/ether 00:06:29:de:56:df brd ff:ff:ff:ff:ff:ff
inet 192.168.1.40/24 brd 192.168.1.255 scope global eth1
# ip route
192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.40
default via 192.168.1.254 dev eth1
[ dmz ]
root@czar:~
# ping -c 3 64.4.197.64
PING 64.4.197.64 (64.4.197.64): 56 data bytes
64 bytes from 64.4.197.69: icmp_seq=0 ttl=255 time=0.425 ms
64 bytes from 64.4.197.65: icmp_seq=0 ttl=255 time=0.773 ms (DUP!)
64 bytes from 64.4.197.68: icmp_seq=0 ttl=128 time=0.823 ms (DUP!)
64 bytes from 64.4.197.69: icmp_seq=1 ttl=255 time=0.137 ms
64 bytes from 64.4.197.68: icmp_seq=1 ttl=128 time=0.356 ms (DUP!)
64 bytes from 64.4.197.65: icmp_seq=1 ttl=255 time=0.433 ms (DUP!)
64 bytes from 64.4.197.69: icmp_seq=2 ttl=255 time=0.120 ms
--- 64.4.197.64 ping statistics ---
3 packets transmitted, 3 packets received, +4 duplicates, 0% packet loss
round-trip min/avg/max = 0.120/0.438/0.823 ms
# ping -c 3 64.4.197.127
PING 64.4.197.127 (64.4.197.127): 56 data bytes
64 bytes from 64.4.197.69: icmp_seq=0 ttl=255 time=0.117 ms
64 bytes from 64.4.197.65: icmp_seq=0 ttl=255 time=0.298 ms (DUP!)
64 bytes from 64.4.197.68: icmp_seq=0 ttl=128 time=0.339 ms (DUP!)
64 bytes from 64.4.197.69: icmp_seq=1 ttl=255 time=0.072 ms
64 bytes from 64.4.197.65: icmp_seq=1 ttl=255 time=0.356 ms (DUP!)
64 bytes from 64.4.197.68: icmp_seq=1 ttl=128 time=0.371 ms (DUP!)
64 bytes from 64.4.197.69: icmp_seq=2 ttl=255 time=0.084 ms
--- 64.4.197.127 ping statistics ---
3 packets transmitted, 3 packets received, +4 duplicates, 0% packet loss
round-trip min/avg/max = 0.072/0.233/0.371 ms
# ip route
64.4.197.64/26 dev eth0 proto kernel scope link src 64.4.197.69
default via 64.4.197.65 dev eth0
# ip addr
. . .
2: eth0: <BROADCAST,PROMISC,NOTRAILERS,UP> mtu 1500 qdisc pfifo_fast
qlen 100
link/ether 00:10:4b:af:ae:e2 brd ff:ff:ff:ff:ff:ff
inet 64.4.197.69/26 brd 64.4.197.127 scope global eth0
inet6 fe80::210:4bff:feaf:aee2/10 scope link
<snip />
> > This is the real problem. If the query reaches dnscache, it processes
> > and answers it, why can't the answer get back to dmz?
>
> I don't know. It could be a variety of reasons, including firewall
> rules, incorrect routing, incorrect packet manipulation (ie masquerading
> one direction but not the other), or ???.
>
> Please provide details related to the above. You claim the query
> reaches dnscache...what makes you think so, and do you have a packet
> dump of the traffic including source & destination IP's and port
> numbers?
I'd be happy to publish more information to the website -- what more do
you need?
> You also indicate dnscache responds to the query...again, what makes you
> think so? Do you have an ipchains log or tcpdump output that would
> verify this? Again, what are the packet source & destination IP's &
> ports?
I see the query and dnscache responses here:
tail -f /var/log/dnscache/* | tai64nlocal
Regarding the details of source ip, &c. -- I'm inclined to think, at
this time, let us repair the errant network setup, then pursue the
dnscache issues.
What do you think?
--
Best Regards,
mds
mds resource
888.250.3987
Dare to fix things before they break . . .
Our capacity for understanding is inversely proportional to how much we
think we know. The more I know, the more I know I don't know . . .
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
------------------------------------------------------------------------
leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
