Charles Steinkuehler wrote: > > > We have a couple sites connected by T-1 to the Internet and the ISP's > > have allocated /26 and /28 public networks for our customers' domains. > > > > As you know, typically T-1's use a public /30 network to connect the > > external wan port to its peer address on the ISP side. This network > > belongs to the ISP and cannot be assigned to the customer. > > > > So, in Dachstein, we do something like this: > > > > wan1_IP_EXTRA_ADDRS="x.y.z.64/26" > > This is not what you really want to do...see below
Yes, but what about the NAT'ed internal network? Does it need a public ip address on the customer's domain? Or, once the domain points entirely to the DMZ, does it *not* matter what public ip address is NAT'ed to the internal network? Will this cause problems if somebody on the internal network wants to run www or ftpd from the internal network? > > During interface initialization, this network gets associated with the > > interface wan1, which also is assigned the ISP's ip address. Is this ip > > aliasing? We're not quite sure why assigning the whole network results > > in only the first address responding to pings from the Internet; but, > > that is moot, for now . . . > > > > What is the best use of that public network in a DMZ ??? > > > > In other words: > > > > [1] We need one (1) ip address associated with the external interface, > > wan1; > > > > [2] We need one (1) ip address associated with the DMZ interface, eth1; > > > > [3] We need two (2) ip addresses, one for the network and one for > > broadcast; and > > > > [4] We want *all* of the rest available on the DMZ. > > You have almost perfectly defined a proxy-arp based DMZ, which is easily > supported with Dachstein. I run several of these personally in similar > circumstances (except I have SDSL instead of T1 :< ) Yes, we have done PROXY_ARP with LRP-CD; but, the publicly visible ip address for the internal network was handled by another network. > > How to configure this with Dachstein-CD ??? > > See the DMZ comments inline in network.conf. Basically: > > wan1_PROXY_ARP=YES > wan1_ROUTES=<DEFAULT_GW> > <intern>_PROXY_ARP=YES > <intern>_ROUTES="x.y.z.64/26" > > DMZ_SWITCH=PROXY > DMZ_EXT_ADDRS="<DEFAULT_GW> <EXTERN_IP>" > DMZ_OPEN_DEST= <as required> > > Your one problem may be that the WAN interface doesn't support proxy-arp...I > don't know if they send ARP packets down the T1 or not. This may not > matter, however, as I think the kernel will do the right thing with the > packets as long as they actually make it to the interface. Since the T1 > link will probably recieve all packets anyway (is there a non-promiscuous > mode for a T1 interface?), I think you'll be OK. > > Let me know how this works out...I can only talk to our T1 through an aging > Cisco 4000 that can't even ssh (IOS 11.2...but it does do nice protocol > based priority queueing :) We're going to try this in a couple hours and we'll let you know. Thank you, again & again . . . -- 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 . . . _______________________________________________ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
