On 6/22/11 10:14 AM, Bernt Hansson wrote:
> 2011-06-22 09:45, Damien Fleuriot skrev:
>> On 6/22/11 9:16 AM, Bernt Hansson wrote:
>>>
>>> Have you tried route add netA netB or route add netB netA
>>>
>>>
>>
>> No offense but please do not give random, untested advice.
>
> No offense, but it is test
2011-06-22 09:45, Damien Fleuriot skrev:
On 6/22/11 9:16 AM, Bernt Hansson wrote:
2011-06-21 13:28, Martin McCormick skrev:
Here is what the issue is right now. The remote campus
in question has been on number space that was part of our Class
B network. They got a block of subnets for thei
On 6/22/11 9:16 AM, Bernt Hansson wrote:
> 2011-06-21 13:28, Martin McCormick skrev:
>> Here is what the issue is right now. The remote campus
>> in question has been on number space that was part of our Class
>> B network. They got a block of subnets for their DNS's and
>> campus enterprises a
2011-06-21 13:28, Martin McCormick skrev:
Here is what the issue is right now. The remote campus
in question has been on number space that was part of our Class
B network. They got a block of subnets for their DNS's and
campus enterprises and work stations. We secured them their own
numbe
> From owner-freebsd-questi...@freebsd.org Tue Jun 21 17:34:22 2011
> From: n j
> Date: Wed, 22 Jun 2011 00:02:53 +0200
> To: freebsd-questions@freebsd.org
> Subject: Re: Two Networks on one System
>
> I can't really say I understand the exact problem the OP has,
As
I can't really say I understand the exact problem the OP has, but if
it's anything similar to asymmetrical/source-based routing problems I
was having some time ago, pf and reply-to is probably the best way to
do it. However, I'd also like to point out setfib(1), as it seems
no-one has brought it up
On 06/21/11 18:45, Damien Fleuriot wrote:
On 6/21/11 6:30 PM, Jerome Herman wrote:
On 06/21/11 12:41, Damien Fleuriot wrote:
This does not depend on the route the client takes, but rather on the IP
the client tries to reach, wouldn't you agree ?
Most of the problems I was afraid of were lifte
On 6/21/11 6:30 PM, Jerome Herman wrote:
> On 06/21/11 12:41, Damien Fleuriot wrote:
>>
>> This does not depend on the route the client takes, but rather on the IP
>> the client tries to reach, wouldn't you agree ?
>
> Most of the problems I was afraid of were lifted when further
> explanations
On 06/21/11 12:41, Damien Fleuriot wrote:
On 6/21/11 2:32 AM, Jerome Herman wrote:
So depending on the client route, packets from a given IP address can
land on either interface. Actually two clients nated behind the same
public address might end up on both interfaces at the same time.
Even th
Damien Fleuriot writes:
> SOLUTION:
> You need a way to reply using a specific route depending on which IP was
> requested by the internet user at 50.50.50.50
>
> If they queried 100.100.100.53, you need to route through 100.100.100.1.
> If they queried 200.200.200.53, you need to route through 20
On 6/21/11 1:28 PM, Martin McCormick wrote:
> Here is what the issue is right now. The remote campus
> in question has been on number space that was part of our Class
> B network. They got a block of subnets for their DNS's and
> campus enterprises and work stations. We secured them their o
> When I set up the secondary interface, I have not been
> able to come up with a statement or statements that tell fxp1
> that it's default router is y.y.y.y so you can't ever reach it
> from outside the new subnet.
What you want to do is called "policy routing" or "source routing",
since
> This, in of itself, doesn't follow. In the absence of stateful firewalls
> and anti-spoofing filtering (blocking packets that don't have a source IP
> address on the "expected" list),
While I can't comment on anyone else's environment, it is in my
experience very common in most corporate and ed
On 6/21/11 7:28 AM, Martin McCormick wrote:
The problem I have, probably due to a misunderstanding
of what I need to do, is easy to describe.
The defaultrouter statement in rc.conf or
route add default x.x.x.x
from the command line sets an interface to know that packets
whose
On 6/21/11 6:41 AM, Damien Fleuriot wrote:
On 6/21/11 2:32 AM, Jerome Herman wrote:
On 21/06/2011 00:13, Jon Radel wrote:
So depending on the client route, packets from a given IP address can
land on either interface. Actually two clients nated behind the same
public address might end up
Here is what the issue is right now. The remote campus
in question has been on number space that was part of our Class
B network. They got a block of subnets for their DNS's and
campus enterprises and work stations. We secured them their own
number space and they are migrating from their po
On Mon, 20 Jun 2011, Martin McCormick wrote:
I would like to say that I got it working, but after
looking at the duel-homed host section of the Handbook, I am
still stuck. A Google search turned up a thread from a couple of
years ago that almost echoed my exact words. We've got a syste
On 6/21/11 2:32 AM, Jerome Herman wrote:
> On 21/06/2011 00:13, Jon Radel wrote:
> So depending on the client route, packets from a given IP address can
> land on either interface. Actually two clients nated behind the same
> public address might end up on both interfaces at the same time.
> Eve
On 6/21/11 12:30 AM, Gary Gatten wrote:
> On 6/20/11 5:07 PM, Martin McCormick wrote:
>
> I was kinda going this route as well - policy based routing type thing, but,
> is there an "easier" way?
>
> 1.) Temporarily enable ipforwarding - not my favorite
> 2.) Instead of a second NIC, bind the n
On 6/20/11 8:32 PM, Jerome Herman wrote:
pass in on nic_a reply-to ($nic_a $gw_a)
pass in on nic_b reply-to ($nic_b $gw_b)
From what I understand, there are two different ISP providing access to
two different interfaces. In this case I am very concerned with all the
bizarre things that a repl
On 21/06/2011 00:13, Jon Radel wrote:
Can networks A and B talk to each other? I suspect not, otherwise
things would be just working even if all traffic went to the primary's
gateway, but I just wanted to check that there wasn't something else
bad happening.
On the assumption that A and B
lliot Finley [mailto:efinley.li...@gmail.com]
Sent: Monday, June 20, 2011 06:18 PM
To: Jon Radel
Cc: freebsd-questions@freebsd.org
Subject: Re: Two Networks on one System
On Mon, Jun 20, 2011 at 4:58 PM, Jon Radel wrote:
>
> On 6/20/11 6:30 PM, Gary Gatten wrote:
>
>> I was kinda
On Mon, Jun 20, 2011 at 4:58 PM, Jon Radel wrote:
>
> On 6/20/11 6:30 PM, Gary Gatten wrote:
>
>> I was kinda going this route as well - policy based routing type thing,
>> but, is there an "easier" way?
>
> Not that I know of given a constraint of completely disjoint networks.
> However, I won't
On 6/20/11 6:30 PM, Gary Gatten wrote:
I was kinda going this route as well - policy based routing type thing, but, is there an
"easier" way?
Not that I know of given a constraint of completely disjoint networks.
However, I won't be too terribly surprised if somebody comes up with
somethin
On 6/20/11 5:07 PM, Martin McCormick wrote:
> We are moving a primary name server from network A to
> network B on one of our branch campuses. If the secondary
> interface was reachable from the world, we can change the whois
> information and not worry about the exact second the change goes
On 6/20/11 5:07 PM, Martin McCormick wrote:
We are moving a primary name server from network A to
network B on one of our branch campuses. If the secondary
interface was reachable from the world, we can change the whois
information and not worry about the exact second the change goes
in
I would like to say that I got it working, but after
looking at the duel-homed host section of the Handbook, I am
still stuck. A Google search turned up a thread from a couple of
years ago that almost echoed my exact words. We've got a system
with network interfaces on two disjointed networ
Matthew Seaman writes:
> Yes. It's common in the sense that a lot of people think its something
> that should work, and get confused when it doesn't prove simple to set up.
Thank you. I think I may have stumbled on to what I need
to do discussed in the Handbook under the multi-homed host
Probably only a single active "default" global ip route, but you can add
network/host routes to prefer a specific interface for said routes.
- Original Message -
From: Martin McCormick [mailto:mar...@x.it.okstate.edu]
Sent: Monday, June 20, 2011 08:37 AM
To: freebsd-questions@freebsd.org
On 20/06/2011 14:37, Martin McCormick wrote:
> Following up on a question I wrote Friday June 17, a
> person from this list kindly referred me to the FreeBSD
> Handbook and the sections on configuring Ethernet interfaces. It
> has an excellent example as to how to set the default gateway
> fr
30 matches
Mail list logo