Abelenda Diego wrote this message on Wed, Sep 16, 2020 at 18:21 +0200:
> Thank you for your input.
>
> Due to how convoluted the change in the configuration of FreeBSD would have
> been I had to completely change my infrastructure to match the vision my
> datacenter unilaterally imposed on me... S
Hello,
Thank you for your input.
Due to how convoluted the change in the configuration of FreeBSD would have
been I had to completely change my infrastructure to match the vision my
datacenter unilaterally imposed on me... So now I don't have this need anymore.
Best regards,
Diego Abelenda
On T
Abelenda Diego wrote this message on Thu, Sep 10, 2020 at 18:54 +0200:
> Hello,
>
> Thank you for pointing route "-iface" however I can't seem to manage what I
> want.
>
> When I use:
> "route add -host $IP_NOT_IN_SUBNET -iface bce0"
>
> I get "netstat -rn" to say someting like:
>
> Internet:
>
10.09.2020 23:54, Abelenda Diego wrote:
> Thank you for pointing route "-iface" however I can't seem to manage what I
> want.
>
> When I use:
> "route add -host $IP_NOT_IN_SUBNET -iface bce0"
>
> I get "netstat -rn" to say someting like:
>
> Internet:
> DestinationGateway
Hello,
Thank you for pointing route "-iface" however I can't seem to manage what I
want.
When I use:
"route add -host $IP_NOT_IN_SUBNET -iface bce0"
I get "netstat -rn" to say someting like:
Internet:
DestinationGateway Flags Netif Expire
default$UPSTREAM_G
09.09.2020 21:42, Abelenda Diego wrote:
> I've got a FreeBSD installation in a DataCenter that provided me with a single
> address IPv4 with an upstream gateway (cidr is fine the upstream gateway works
> everything is nice and running). I use this machine for Masquerading an
> private
> infrastru
Le Wed, 9 Sep 2020 16:42:54 +0200,
Abelenda Diego a écrit :
> Hello,
>
> I've got a FreeBSD installation in a DataCenter that provided me with a single
> address IPv4 with an upstream gateway (cidr is fine the upstream gateway works
> everything is nice and running). I use this machine for Masqu
Hello Cristian,
Thank you for your pointer, however if I quote part of my question:
> From my understanding in FreeBSD the route command is unable to perform this
> kind of configuration where you tell that the IPv4 /32 is available without
> next-hop (no via) on a specific link.
I imply there th
Hi
The equivalent command in FreeBSD for the ip route is the route,
follow manpage https://www.freebsd.org/cgi/man.cgi?route
Em qua., 9 de set. de 2020 às 11:43, Abelenda Diego
escreveu:
>
> Hello,
>
> I've got a FreeBSD installation in a DataCenter that provided me with a single
> address IPv4 w
Hello,
I've got a FreeBSD installation in a DataCenter that provided me with a single
address IPv4 with an upstream gateway (cidr is fine the upstream gateway works
everything is nice and running). I use this machine for Masquerading an private
infrastructure.
Now I need other machines with publi
sepherosa_gmail.com abandoned this revision.
REVISION DETAIL
https://reviews.freebsd.org/D8904
EMAIL PREFERENCES
https://reviews.freebsd.org/settings/panel/emailpreferences/
To: sepherosa_gmail.com, delphij, royger, decui_microsoft.com,
honzhan_microsoft.com, howard0su_gmail.com, adrian, bz
glebius added a comment.
I don't think that the patch is in the right direction. The problem comes
from historical behavior that assigning an address is implicit UP. For a modern
networking equipment it is a normal administrative situation that sysadmin
wants to assign an address or an alias
sepherosa_gmail.com added a comment.
In https://reviews.freebsd.org/D8904#185970, @karels wrote:
> I think the change is a step in the right direction. Certainly, "ifconfig
xxN down" followed by an implicit UP should not cause any change to the routing
table. Does anyone know why the "
karels added a comment.
I think the change is a step in the right direction. Certainly, "ifconfig
xxN down" followed by an implicit UP should not cause any change to the routing
table. Does anyone know why the "down" is removing the route? That seems
wrong to me.
REVISION DETAIL
https:
Michael Grimm wrote:
Nevermind, I solved my issue. I has been a minor typo with major consequences.
> Configuration (shown for hostA, only):
>
> setkey.conf
> # hostA hostB
> hostA hostB
> spdadd 10.1.1.0/
he bridge.
#) Whenever an IP bound to ix0 is involved (host to jail) the
corresponding spdadd parts are recognised.
#) adding static routes like "add route 10.2.2.0/24 1.2.3.4" and alike
do not solve my issue.
Questions:
#) Is this an issue with IPsec/racoon?
sepherosa_gmail.com added a comment.
In https://reviews.freebsd.org/D8904#184430, @hrs wrote:
> The cause is that the prefix route was removed by in_scrubprefix() in the
PRC_IFDOWN handler and never reinstalled upon PRC_IFUP because the
reinstallation is done only for ifa passed to SIOC
hrs added a comment.
The cause is that the prefix route was removed by in_scrubprefix() in the
PRC_IFDOWN handler and never reinstalled upon PRC_IFUP because the
reinstallation is done only for ifa passed to SIOCAIFADDR. Just calling
if_up(ifp) looks too heavy to me because it causes extra
sepherosa_gmail.com created this revision.
sepherosa_gmail.com added reviewers: delphij, royger, decui_microsoft.com,
honzhan_microsoft.com, howard0su_gmail.com, adrian, bz, gnn, hiren, glebius,
rwatson, karels.
sepherosa_gmail.com added a subscriber: freebsd-net-list.
REVISION SUMMARY
This
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207877
Mark Linimon changed:
What|Removed |Added
Assignee|freebsd-b...@freebsd.org|freebsd-net@FreeBSD.org
--
You are
04.03.2016 22:16, Julian Elischer пишет:
On 3/03/2016 2:38 AM, Pakhom Golynga wrote:
Hello all!
Please help me to investigate this issue.
I have problem on 10.2-RELEASE-p12 with multiple network interfaces
and PF (rules, NAT)
# ifconfig
<--cut-->
em0: flags=8843 metric 0 mtu
1500
options=4
On 3/03/2016 2:38 AM, Pakhom Golynga wrote:
Hello all!
Please help me to investigate this issue.
I have problem on 10.2-RELEASE-p12 with multiple network interfaces
and PF (rules, NAT)
# ifconfig
<--cut-->
em0: flags=8843 metric 0 mtu
1500
options=4209b
ether 00:25:90:64:14:50
Hello all!
Please help me to investigate this issue.
I have problem on 10.2-RELEASE-p12 with multiple network interfaces and
PF (rules, NAT)
# ifconfig
<--cut-->
em0: flags=8843 metric 0 mtu 1500
options=4209b
ether 00:25:90:64:14:50
inet 172.27.27.254 netmask 0xff00 broa
Hello all!
Please help me to investigate this issue.
I have problem on 10.2-RELEASE-p12 with multiple network interfaces and
PF (rules, NAT)
# ifconfig
<--cut-->
em0: flags=8843 metric 0 mtu 1500
options=4209b
ether 00:25:90:64:14:50
inet 172.27.27.254 netmask 0xff00 broa
Hello all!
Please help me to investigate this issue.
I have problem on 10.2-RELEASE-p12 with multiple network interfaces and
PF (rules, NAT)
# ifconfig
<--cut-->
em0: flags=8843 metric 0 mtu 1500
options=4209b
ether 00:25:90:64:14:50
inet 172.27.27.254 netmask 0xff00 broa
On 01/23/15 15:13, VANHULLEBUS Yvan wrote:
Hi.
On Wed, Jan 21, 2015 at 03:16:21PM +0100, Andrei Brezan wrote:
Weird subject, maybe.
I'm running FreeBSD-10.0-RELEASE with PF as firewall and racoon for
IPSEC. The IPSEC tunnel is between the FreeBSD box and a Fortinet
appliance.
The IPSEC tunnel
Hi.
On Wed, Jan 21, 2015 at 03:16:21PM +0100, Andrei Brezan wrote:
> Weird subject, maybe.
>
> I'm running FreeBSD-10.0-RELEASE with PF as firewall and racoon for
> IPSEC. The IPSEC tunnel is between the FreeBSD box and a Fortinet
> appliance.
>
> The IPSEC tunnel comes up and on a quick test it
Weird subject, maybe.
I'm running FreeBSD-10.0-RELEASE with PF as firewall and racoon for
IPSEC. The IPSEC tunnel is between the FreeBSD box and a Fortinet appliance.
The IPSEC tunnel comes up and on a quick test it seems to be working,
icmp between networks is ok, you can successfully telnet
ourse are
>>> received and not sent out anywhere)?
>>>
>> Yes, when the go through they go to external address, which is in the
>> routing table.
>>
>>>
>>> I guess the above new log lines should show the interface (if any)
>>> these packets a
ss you're sure that these packets are actually going out to some
>> external address, not a localhost or alias address (which of course are
>> received and not sent out anywhere)?
>>
> Yes, when the go through they go to external address, which is in the
> routing tabl
are
> received and not sent out anywhere)?
>
Yes, when the go through they go to external address, which is in the
routing table.
>
> I guess the above new log lines should show the interface (if any)
> these packets are leaving on, after routing (maybe a routing issue?)
>
&
On Wed, 5 Mar 2014 20:44:51 +0100, Andreas Nilsson wrote:
> On Wed, Mar 5, 2014 at 7:49 PM, Andrey V. Elsukov wrote:
>
> > On 04.03.2014 09:58, Andreas Nilsson wrote:
> > > Why do I need the explict fwd rule? As far as I can see the ipfw man page
> > > says nothing about skipto changing the
On 05.03.2014 23:44, Andreas Nilsson wrote:
> With the above ruleset a packet
> 1) triggering the first rule ( ie skipto no-op and the allow from any to
> any ) is lost.
> 2) triggering the second rule (ie skipto divert rule which returns it to
> the stack ) is forwarded.
So, I don't see in the co
On Wed, Mar 5, 2014 at 7:49 PM, Andrey V. Elsukov wrote:
> On 04.03.2014 09:58, Andreas Nilsson wrote:
> > Why do I need the explict fwd rule? As far as I can see the ipfw man page
> > says nothing about skipto changing the packets, and since the 65533 rule
> in
> > the second ruleset triggers on
On 04.03.2014 09:58, Andreas Nilsson wrote:
> Why do I need the explict fwd rule? As far as I can see the ipfw man page
> says nothing about skipto changing the packets, and since the 65533 rule in
> the second ruleset triggers on the same thing as the skipto rule it would
> seem like packets are "
Hello Raimundo
On Wed, Mar 5, 2014 at 2:26 PM, Raimundo Santos wrote:
> Hello, Andreas.
>
> If table(12) is empty, how will fwd know where to send the packets that
> hits it?
>
My understanding is that the rule should not be triggered, as the "... from
table(12)" will not match any packets. Othe
Hello, Andreas.
If table(12) is empty, how will fwd know where to send the packets that
hits it?
Best regards,
Raimundo
On 4 March 2014 02:58, Andreas Nilsson wrote:
> Hello,
>
> I'm having a strange problem with ipfw and/or routing. I've only tested
> this on 9.2-RELEASE-p3, amd64. The machi
Hello,
I'm having a strange problem with ipfw and/or routing. I've only tested
this on 9.2-RELEASE-p3, amd64. The machine is sort of acting as router. The
ruleset is like (ipfw defaults to accept):
$cmd="ipfw -fq "
$cmd add 1 skipto 65534 log all from "table(1)" to any in recv "table(8)"
...
$
t: Mon 1/25/2010 4:47 AM
> To: freebsd-net@freebsd.org; freebsd-curr...@freebsd.org
> Subject: tun setup (routing?) issue in head
>
>
>
>
> I've updated my HEAD amd64 system from December's sources to something more
> recent
> and I've got problems with securi
From: owner-freebsd-curr...@freebsd.org on behalf of Andriy Gapon
Sent: Mon 1/25/2010 4:47 AM
To: freebsd-net@freebsd.org; freebsd-curr...@freebsd.org
Subject: tun setup (routing?) issue in head
I've updated my HEAD amd64 system from December's sources to something more
recen
I've updated my HEAD amd64 system from December's sources to something more
recent
and I've got problems with security/vpnc. To be precise vpnc itself seems to
work
as good as before but its post-connect script is now failing:
$ ifconfig tun0 inet 10.99.15.144 10.99.15.144 netmask 255.255.255.2
Hello networkers,
We have a strange issue that currently happened at our router.
information:
OS : FreeBSD 4.11-STABLE #1: Tue Jun 7 19:21:04 WIT 2005
Routing Software : quagga-0.98.3 (compiling from ports)
Network: Running eBGP (with full international route 16k p
hello, everyone.
i've got a funny network layout (it's in transition) and am seeing
behaviour from FreeBSD 5.2.1 that's different from an Alcatel 6600-24
and a Nortel 1424T router. that is, when i use FreeBSD to do my routing
everything works, but when i use either of the other routers things
43 matches
Mail list logo
