Charles Steinkuehler wrote: > > 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).
Remember, this is ip route for the old, proxy-arp dmz . . . <snip /> > 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 don't have that here; must wait to retrieve from an associate later . . . > 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 <snip /> > 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!). OK <snip /> > > # 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. Remember, this is the new, non-proxy-arp dmz . . . <snip /> > > 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. Yes, looks pretty dumb; but, we have these mapped to systems on NAT'ed internal network. Besides, I have done same testing *without* these and results are identical . . . <snip /> > > # 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. What, pray tell, are those DUP! lines? <snip /> > > # 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. Pretty cool, huh? I'm also more than a little mystified . . . <snip /> > > 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? See other posts and corresponding webpage -- tail -f /var/log/dnscache/* <snip /> -- 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
