SEO
vBulletin Search Engine Optimization
| |||||||
| Register | FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
02-18-2008, 06:48 AM
| ||||
| ||||
 Re: routing problem Hello Guillaume, Thank you for your reply  I have looked at this program and it will fix the problem. However I do not understand why I have to proxy ARP packets if I dont want 196.14.164.129 to act as if its on the local segment. I want the packet to come into the openbsd box on fxp0 and get re-routed to 196.23.168.18 (vlan3). I did a similar set up at our test labs using FreeBSD and RFC1918 IP address's and it worked without a problem thats why I dont understand why this is happening.Regards Mark On Feb 19, 2004 03:57 PM, Guillaume Tournat <g.tournat@pcl.fr> wrote: > the problem is that the server wants to know the MAC address of the > destination (ARP protocol). on my firewall, when i used binat, i had > to install arpcatch package too. it's a soft which broadcast mac > address on behalf of machines which are behind the firewall. > > is that it ? > > > mines still not resolved.. Im not running NAT at all.. Using all internet > > address space. > > > > Let me maybe rephrase my problem and add some more information.. > > > > From the OpenBSD server I can ping 196.14.164.129. If I log into another > > server on a different vlan I can traceroute and ping 196.14.164.129. If I try > > this from a external server all I get on tcpdump is: > > > > uplink-rtr-jhb:~# tcpdump -i fxp0 host 196.14.164.129 > > tcpdump: listening on fxp0 > > 14:54:38.906715 arp who-has 196.14.164.129 tell 168.209.87.69 > > > > What I think is happening is the OpenBSD server does not route the packet via > > the destination and automatically assumes that this address is on the local > > network. > > > > Here is what my setup looks like: > > > > route add 196.14.164.0/24 196.23.168.18 > > > > PF is disabled.. > > > > fxp0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MU LTICAST> mtu 1500 > > address: 00:07:e9:5a:c5:c6 > > media: Ethernet autoselect (10baseT) > > status: active > > inet 168.209.87.70 netmask 0xfffffffc broadcast 168.209.87.71 > > inet6 fe80::207:e9ff:fe5a:c5c6%fxp0 prefixlen 64 scopeid 0x6 > > > > vlan3: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 > > address: 00:a0:24:4a:84:f3 > > vlan: 5 parent interface: xl0 > > inet6 fe80::2a0:24ff:fe4a:84f3%vlan3 prefixlen 64 scopeid 0x17 > > inet 196.23.168.17 netmask 0xfffffffc broadcast 196.23.168.19 > > > > Thanks > > Mark > > > > > > On Feb 19, 2004 05:03 AM, Len Jacobs <ljacobs@mandala-designs.com> wrote: > > > > > The routing problem was resolved... Surprise! > > > > > > I guess it might be a helpful listing in the FAQ, should be so obvious, > > > but it was not. Unless NAT is setup & running (via pfctl/pf.conf) > > > internal (nonroutable) IPs from the LAN cannot effectively reach the > > > Internet (WAN). The internal addresses need a route back from the > > > outside which is just what NAT provides. > > > > > > So running NAT resolved the non-routing problem I had been experiencing. > > > Works like a charm now. > > > > > > Thansk for everyone's comments and suggestions. > > > > > > > > > Bonjour, > > > > > Cordialement, > Guillaume Tournat___________________________________ > PCL - 8-10 rue Jean Jaures - FR-86000 POITIERS > Tel: +33 5 49 60 68 60 - Fax: +33 5 49 41 49 14 > Mel: g.tournat@pcl.fr - Web: www.pcl.fr > __________________________________________________ __ > > -- > Merci de n'utiliser dans vos courriers que des formats > libres : textes (txt, rtf, html, pdf), images (png, jpg) > http://www.fsf.org/philosophy/no-word-attachments.html      |
Linear Mode
