Comments inline. > 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
This looks OK, assuming your ISP is routing the 64.4.197.64/26 subnet to your WAN IP. Some traceroutes indicate this is what's happening (more on that later). > I, too, have been confused by this errant ping-ability of 64.4.197.64 & > 64.4.197.127. I show your network and broadcast IP's not passing the WAN link (either stopped by your ISP, or perhaps being blocked by your firewall). (more details later) > > 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> This is how your local system is setup...I was looking more for what your ISP told you about your public IP's (if anything). Typically on the sheet of "technical details" along with stuff like your DNS and e-mail servers... I have attempted to extract what your ISP is doing by running some traceroutes: [root@falcon root]# for DEST in 63 64 65 99 127 128 ; do > echo ; traceroute -nf 17 -w 2 -m 20 64.4.197.$DEST ; done traceroute to 64.4.197.63 (64.4.197.63), 20 hops max, 38 byte packets 17 207.112.240.6 33.126 ms 31.852 ms 31.878 ms 18 198.77.87.23 32.008 ms 32.082 ms 32.722 ms 19 64.4.222.149 41.858 ms 35.428 ms 38.185 ms 20 * * * traceroute to 64.4.197.64 (64.4.197.64), 20 hops max, 38 byte packets 17 207.112.240.6 32.083 ms 31.944 ms 31.975 ms 18 198.77.86.6 33.398 ms 32.858 ms 33.478 ms 19 * * * 20 * * * traceroute to 64.4.197.65 (64.4.197.65), 20 hops max, 38 byte packets 17 207.112.240.6 32.178 ms 31.792 ms 31.765 ms 18 198.77.86.6 32.937 ms 33.318 ms 33.326 ms 19 64.4.197.65 35.959 ms 36.572 ms 36.171 ms traceroute to 64.4.197.99 (64.4.197.99), 20 hops max, 38 byte packets 17 207.112.240.6 32.233 ms 32.058 ms 31.694 ms 18 198.77.86.6 32.949 ms 33.293 ms 32.905 ms 19 64.4.197.99 36.490 ms 37.303 ms 36.228 ms traceroute to 64.4.197.127 (64.4.197.127), 20 hops max, 38 byte packets 17 207.112.240.6 31.895 ms 31.948 ms 32.092 ms 18 198.77.86.6 34.647 ms 32.985 ms 33.083 ms 19 * * * 20 * * * traceroute to 64.4.197.128 (64.4.197.128), 20 hops max, 38 byte packets 17 207.112.240.6 31.946 ms 32.336 ms 31.957 ms 18 * * * 19 * * * 20 * * * Note the reachability of systems you have assigned IP's to (.65, .99, & .101), the fact that systems you don't have configured but are within your subnet are routed to your firewall (.98 & .102), and that your network and broadcast IP's follow the same path, but don't get a response from your firewall (.64 & .127). All of this indicates to me that your ISP is routing the entire /26 network to your firewall, so you have a classic "routed" DMZ, with 61 usable IP's (woo-hoo!). > > 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 This looks much more appropriate than the proxy-arp based rules previously posted. > Resulting rules are here: > > <http://www.helices.org/tmP/ipchains.no_proxy_arp.bluetrout.txt> Digesting... > # 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 Looks good. > 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 Please *REMOVE* the extra IP's assigned to your wan interface and see what happens (ie wan1 should have *ONLY* the 64.4.222.157 IP). The fact that you have IP's assigned to the firewall that actually belong on your DMZ network could be the source of all your confusion. Remember, the wan interface is an arpless point-to-point interface, and even if wan1 was an ethernet NIC, your IP configuration would not work in either a routed *OR* a proxy-arp DMZ. > 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 This is as expected, and even makes sense. > [ 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 I'm confused as to why the responding IP is the internal IP of your firewall, rather than an IP on your DMZ network. > # 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 expected and normal. > > > 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? Just wondering what made you think a DNS query arrived. Tcpdump? Packet log? Something else? > > 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? Sounds like a good plan. Please *REMOVE* the extra IP's from your WAN interface, and see if that helps things. Note that as far as the firewall is concerned, it could very well be trying to "talk to itself", since you've got the DMZ IP's assigned to the wan interface. There could be some variations on routes packets take through ipchains & the kernel IP stack that allows externally generated "router" traffic to pass correctly to the DMZ, but causes locally generated response packets to go to wan1, despite your routing table entries. I'm still digesting your firewall rules and next post... Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ------------------------------------------------------- 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
