Re: IP "routing" issue

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...

Re: IP "routing" issue

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

Re: IP "routing" issue

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:

Re: IP "routing" issue

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

Re: IP "routing" issue

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

Re: IP "routing" issue

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 >

Re: IP "routing" issue

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

Re: IP "routing" issue

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

Re: IP "routing" issue

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

IP "routing" issue

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

[Differential] D8904: inet: Fix routing issue by calling if_up()

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,

[Differential] D8904: inet: Fix routing issue by calling if_up()

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

[Differential] D8904: inet: Fix routing issue by calling if_up()

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

[Differential] D8904: inet: Fix routing issue by calling if_up()

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

[SOLVED] IPSec tunnel, VNET jail and routing issue

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 >

IPSec tunnel, VNET jail and routing issue

#) 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? #) Is this

[Differential] D8904: inet: Fix routing issue by calling if_up()

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

[Differential] D8904: inet: Fix routing issue by calling if_up()

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

[Differential] D8904: inet: Fix routing issue by calling if_up()

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

[Bug 207877] routing issue (some routes seem to stop being effective after some period)

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207877 Mark Linimon changed: What|Removed |Added Assignee|freebsd-b...@freebsd.org

Re: routing issue

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:

Re: routing issue

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

routing issue

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

routing issue

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

routing issue

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

Re: IPSEC MTU routing issue

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 seems

IPSEC MTU routing issue

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

Re: ipfw / routing issue on 9.2-RELEASE

(maybe a routing issue?) Good luck hunting. If in doubt, throw ever more logging at it! :) And please let the list know if you solve it - or not! cheers, Ian To make it even more interesting, it tested this on another machine, where I'm unable to reproduce this problem. I'm thinking

Re: ipfw / routing issue on 9.2-RELEASE

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?) Good luck hunting. If in doubt, throw ever more

Re: ipfw / routing issue on 9.2-RELEASE

of course 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?) Good luck hunting

Re: ipfw / routing issue on 9.2-RELEASE

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 andrn...@gmail.com wrote: Hello, I'm having a strange problem with ipfw and/or routing. I've only tested this on 9.2-RELEASE-p3,

Re: ipfw / routing issue on 9.2-RELEASE

Hello Raimundo On Wed, Mar 5, 2014 at 2:26 PM, Raimundo Santos rait...@gmail.com 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

Re: ipfw / routing issue on 9.2-RELEASE

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

Re: ipfw / routing issue on 9.2-RELEASE

On Wed, Mar 5, 2014 at 7:49 PM, Andrey V. Elsukov bu7c...@yandex.ru 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

Re: ipfw / routing issue on 9.2-RELEASE

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 code

Re: ipfw / routing issue on 9.2-RELEASE

On Wed, 5 Mar 2014 20:44:51 +0100, Andreas Nilsson wrote: On Wed, Mar 5, 2014 at 7:49 PM, Andrey V. Elsukov bu7c...@yandex.ru 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

ipfw / routing issue on 9.2-RELEASE

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) ... $cmd

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 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

Re: tun setup (routing?) issue in head

@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 security/vpnc. To be precise vpnc itself seems to work as good as before but its post

Strange Routing issue

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