Re: public ip address behind nat

> I want to assign to application.example.com 193.231.43.27 and to route this i p trough nat.example.com > > Any ideea how can i do that ? > Please help. Mihai, From the man page of natd: -unregistered_only | -u Only alter outgoing packets with an unregistered source

Re: [PATCH] 802.1p priority (fixed)

On Tue, Jan 25, 2005 at 09:16:02AM +0500, Boris Kovalenko wrote: > Hello! > > >by this specific implementation. I'm sure we can keep an interface that > >handles priorities as seperate interfaces, but I'm not sure we'll want > >to do it via the vlan device (attractivly simple though that is.) > >

Re: [PATCH] 802.1p priority (fixed)

Hello! by this specific implementation. I'm sure we can keep an interface that handles priorities as seperate interfaces, but I'm not sure we'll want to do it via the vlan device (attractivly simple though that is.) This patch appears to be against 4 or 5. In 6 we've largly rewritten ifconfig so

mpd pptp packet loss xp client

The packet loss issue with pptp connections from xp clients to mpd servers appears to be a windows firewall issue. Disabling windows firewall solved my problem. It doesn't look like the standard xp firewall knows how to handle gre or ppp protocols. I attempted adding tcp port 1723 to the list of

Re: public ip address behind nat

On Mon, Jan 24, 2005 at 03:21:19PM -0800, Mihai Nitulescu wrote: > I want to assign to application.example.com 193.231.43.27 and to route this > ip trough nat.example.com If you have control over the NAT device, you could set up a point-to-point tunnel from the NAT device to the machine in the NA

Re: gif(4) and bpf(4)

On Mon, Jan 24, 2005 at 10:20:11PM +0100, Jeremie Le Hen wrote: > Is it supposed to work or not ? If not, does it work on RELENG_5 ? > My very -CURRENT laptop succeeds in opening bpf(4) on a gif(4) interface. In a previous existence, I was able to tcpdump on a gif(4) interface; the tunnel was bei

gif(4) and bpf(4)

Hi, I set up a VPN between a RELENG_4 and a another box. Everything works well except I can't use tcpdump(8) on the gif(4). IIRC it's a well-known problem - I already saw this topic here but can't find these posts again - but I cannot understand why it doesn't work since if_gif.c in RELENG_4 has

public ip address behind nat

Hi Can anyone help me out with an issue that i have? I run 2 FreeBSD 5.3 machines. First nat.example.com has 2 NIC`s rl0 (193.231.43.33) rl1(192.168.0.254) The machine runs NAT for my LAN (192.168.0.0/24) In the LAN i have the other machine application.example.com I have some Public IP`s fro

Re: Making ICMP the default traceroute protocol?

> I disagree. Firstly, IWFs tend to also block ICMP. Secondly, routers > sometimes queue ICMP differently than UDP (not just in their own > processing, which they almost always do, but also in their forwarding), > giving even more distortion to these data than they naturally possess > otherwi

[Fwd: Re: Making ICMP the default traceroute protocol?]

Marian Durkovic wrote: seems that in today's networking environment the original traceroute concept utilising high UDP ports no longer works - since those ports are now typically blocked by firewalls. However, when traceroute is performed using ICMP protocol, the results are much better. Th

Re: [PATCH] 802.1p priority (fixed)

On Mon, Jan 24, 2005 at 08:32:12AM +0500, Boris Kovalenko wrote: > Brooks Davis wrote: > Hello! > > > > > > >I still don't see how this usefull differs from taking action or not > >taking action. > Just more simple to understand (trusted or not trusted vlan (IMHO)), but > taking action via IPFW o

Making ICMP the default traceroute protocol?

Hi all, seems that in today's networking environment the original traceroute concept utilising high UDP ports no longer works - since those ports are now typically blocked by firewalls. However, when traceroute is performed using ICMP protocol, the results are much better. Therefore,

Re: New failure detection algorithm for ng_one2many(4).

> Hello. > > Patch below adds new failure detection algorithm for ng_one2many(4). > For now, the only such algorithm doesn't detect failures, one have > to show active links manually. > >http://garage.freebsd.pl/patches/netgraph_one2many.patch > > The way how to use this module (ng_one2man

Current problem reports assigned to you

Current FreeBSD problem reports Critical problems Serious problems S Submitted Tracker Resp. Description --- o [2002/07/26] kern/41007 net overfull traffic on third and fourth adap 1 problem total.

[TEST/REVIEW #2] ng_ipfw: node to glue together ipfw(4) and netgraph(4)

Dear collegues, pls review an updated patch bringing in ng_ipfw node. Differencies against previous patch: - packets coming from netgraph are queued, and later serviced by netisr - "ngtee" keyword introduced. A copy of packet is made, and it is sent into netgraph. No tagging is done. Original