On Friday 01 October 2004 16:21, Leon Garde wrote:
> The other way to route by source is to use a rule like this
>
> 'ipfw add 1 fwd 192.168.10.2 from 192.168.0.3 to any '
Thanks! That did the job, and now 192.168.0.3 is being routed to the inet via
tun0.
on HOST_B (local router), rules now
On Fri, Oct 01, 2004 at 03:32:34PM -0400, Wesley Shields wrote:
> Per a message about a month ago[1] I recently started some work on
> adding a -v flag to ifconfig. I've been able to get the index number
> and epoch as those are exposed to userland, but both the dname and dunit
> are in an ifnet s
Per a message about a month ago[1] I recently started some work on
adding a -v flag to ifconfig. I've been able to get the index number
and epoch as those are exposed to userland, but both the dname and dunit
are in an ifnet struct which AFAIK is not visible. I initially thought
you might be able
Confusion 1. nat replaces routing.
Mikail says he cant get routing to work, so he is using nat.
Seems to me that to get nat going, he needs to fix the routing.
Confusion 2.
The sentiment "routing is hard" is wrong. Routing is easy.
routes specify where to send a packet based on where it is g
Got a question about routing with regards to MPD. I'm able to make
connections to my MPD-based VPN server just fine, but once connected, I
can't communicate with anything on the other side of the tunnel, and it
appears to be a routing problem.
My ifconfig results for the ng0 device on the MPD ser
On Friday 01 October 2004 08:18, Mikhail P. wrote:
> Basically we got back to the point where we
> all started - I can ping remote party (HOST_B) from 192.168.0.x, but no
> further.
Sorry, supposed to be HOST_A in above sentence.
regards,
M.
___
[EMAIL
On Friday 01 October 2004 07:38, Juhani Tali wrote:
>
> ipfw add 4 divert 8568 ip from 192.168.0.3 to any out xmit tun0
> ipfw add 6 divert 8568 ip from any to any in recv tun0
>
>
> replace these with
> ipfw add 4 divert 8568 ip from 192.168.0.3 to any
> prior to this rule the packet was
On Fri, Oct 01, 2004 at 12:14:53PM +0400, Gleb Smirnoff wrote:
T> This patch is intended to fix interoperation
and the patch is in this message.
--
Totus tuus, Glebius.
GLEBIUS-RIPN GLEB-RIPE
Index: netgraph/ng_ether.c
===
RCS fil
This patch is intended to fix interoperation
between bridge(4) and ng_ether(4). The problem is described
in this message:
http://lists.freebsd.org/mailman/htdig/freebsd-net/2004-May/003881.html
I hope that some CURRENT bridge users will help me testing it.
After applying patch you need to:
#
Mikhail P. wrote:
On Friday 01 October 2004 06:51, Juhani Tali wrote:
Did not quite understand what you meant here.
ended up running natd on tun0 of HOST_B as:
natd -interface rl1
natd -port 8568 -interface tun0
I should have read it as HOST_A, because HOST_B does not have a rl1,
only rl
On Wed, Sep 29, 2004 at 10:05:21PM +0300, Kalin Hristov wrote:
K> It would be very nice
K> As they say about the MPLS "The feature of the Internet"
This is a very big piece of work to be done. In my humble
opinion it would be at least one year of full time work
for a couple of developers. It also
On Friday 01 October 2004 06:51, Juhani Tali wrote:
> I would set it up like so:
>
> This one in host B
>
> > natd -interface rl1
>
> And this in host A
>
> > natd -port 8568 -interface tun0
>
> You need to translate all the 192.168.0.x to tunnel's address and you
> cannot do it in host B, because
12 matches
Mail list logo
