Re: IP "routing" issue

[John-Mark Gurney]

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... So now I don't have this need 
> anymore.

Ok.  Glad you were able to solve your problem, though obviously not the way you
wanted to.

Just for the archives, this style of routing should work fine in FreeBSD.

> On Tue, 15 Sep 2020 12:10:52 -0700
> John-Mark Gurney  wrote:
> 
> > 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:
> > > DestinationGateway   Flags Netif Expire
> > > default$UPSTREAM_GW  UGSbce0
> > > 10.0.0.1   link#7UHS lo0
> > > $IP_NO_IN_SUBNET   $MAC_ADDRESS_OF_BCE0  UHSbce0
> > > 
> > > 
> > > Which seem somehow appropriate, so I try to ping $IP_NOT_IN_SUBNET and I
> > > get:
> > > 
> > > root@opnsense2:~ # ping $IP_NOT_IN_SUBNET
> > > PING $IP_NOT_IN_SUBNET ($IP_NOT_IN_SUBNET): 56 data bytes
> > > 36 bytes from $UPSTREAM_GW: Redirect Host(New addr: $PUBLIC_IP_OF_BCE0).
> > > 
> > > Which doesn't seem appropriate at all wrt the routing table...
> > > 
> > > Did I use "route add" wrong?
> > > 
> > > Also I want to keep the setup simple, going through private IPs on the
> > > public VLAN of the datacenter might get me in trouble with them, and using
> > > other VLANs for that will be a pain.  
> > 
> > Can you provide a diagram of the network layout, and where the
> > configuration needs to go?  Because if it's just the opnsense box that
> > needs the IP addresses, adding them as an alias to bce is enough to
> > make it work.
> > 
> > If you're trying to do something else, like have boxes behind the
> > opnsense box have those IP addresses, then:
> > route add $IP_NO_IN_SUBNET $IP_OF_BOX_WITH_IP_NO_IN_SUBNET
> > 
> > would just work.
> > 
> > I just noticed the 10.0.0.1 IP on lo0, and that's a bit odd to have...
> > 
> > > On Wed, 9 Sep 2020 17:35:45 +0200
> > > kaycee gb  wrote:
> > >   
> > > > 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
> > > > > Masquerading an private infrastructure.
> > > > > 
> > > > > Now I need other machines with public IPv4 and when I requested the
> > > > > additional IPv4 to the DataCenter, they gave me a bunch of /32 
> > > > > addresses
> > > > > saying that my previous IPv4 MUST be configured as next-hop on their
> > > > > side. 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 know the
> > > > > linux "ip route add $IP dev $LINK" configures this, but I cannot seem
> > > > > to map this knowledge to FreeBSD.
> > > > > 
> > > > > Is it possible to perform this very special setup with any command on
> > > > > FreeBSD? If yes what is that command?
> > > > > 
> > > > > Best regards,
> > > > > Diego Abelenda
> > > > 
> > > > Hi,
> > > > 
> > > > Do the other machines have a private address ? Is it a problem if they
> > > > have one ? 
> > > > If it is possible, you can route via this private address on your 
> > > > FreeBSD
> > > > installation to the new one and assign a public/32 to the last.
> > > > 
> > > > Alternatively to doing routing like above, if you have a firewall 
> > > > enabled
> > > > on the first machine, you can do address forwarding between the first 
> > > > and
> > > > the new one. 
> > > > 
> > > > And last, maybe with something like -iface from "route" you can achieve
> > > > what you want.   


-- 
  John-Mark Gurney  Voice: +1 415 225 5579

 "All that I will do, has been done, All that I have, has not."


signature.asc
Description: PGP signature

Re: IP "routing" issue

[Abelenda Diego]

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 Tue, 15 Sep 2020 12:10:52 -0700
John-Mark Gurney  wrote:

> 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:
> > DestinationGateway   Flags Netif Expire
> > default$UPSTREAM_GW  UGSbce0
> > 10.0.0.1   link#7UHS lo0
> > $IP_NO_IN_SUBNET   $MAC_ADDRESS_OF_BCE0  UHSbce0
> > 
> > 
> > Which seem somehow appropriate, so I try to ping $IP_NOT_IN_SUBNET and I
> > get:
> > 
> > root@opnsense2:~ # ping $IP_NOT_IN_SUBNET
> > PING $IP_NOT_IN_SUBNET ($IP_NOT_IN_SUBNET): 56 data bytes
> > 36 bytes from $UPSTREAM_GW: Redirect Host(New addr: $PUBLIC_IP_OF_BCE0).
> > 
> > Which doesn't seem appropriate at all wrt the routing table...
> > 
> > Did I use "route add" wrong?
> > 
> > Also I want to keep the setup simple, going through private IPs on the
> > public VLAN of the datacenter might get me in trouble with them, and using
> > other VLANs for that will be a pain.  
> 
> Can you provide a diagram of the network layout, and where the
> configuration needs to go?  Because if it's just the opnsense box that
> needs the IP addresses, adding them as an alias to bce is enough to
> make it work.
> 
> If you're trying to do something else, like have boxes behind the
> opnsense box have those IP addresses, then:
> route add $IP_NO_IN_SUBNET $IP_OF_BOX_WITH_IP_NO_IN_SUBNET
> 
> would just work.
> 
> I just noticed the 10.0.0.1 IP on lo0, and that's a bit odd to have...
> 
> > On Wed, 9 Sep 2020 17:35:45 +0200
> > kaycee gb  wrote:
> >   
> > > 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
> > > > Masquerading an private infrastructure.
> > > > 
> > > > Now I need other machines with public IPv4 and when I requested the
> > > > additional IPv4 to the DataCenter, they gave me a bunch of /32 addresses
> > > > saying that my previous IPv4 MUST be configured as next-hop on their
> > > > side. 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 know the
> > > > linux "ip route add $IP dev $LINK" configures this, but I cannot seem
> > > > to map this knowledge to FreeBSD.
> > > > 
> > > > Is it possible to perform this very special setup with any command on
> > > > FreeBSD? If yes what is that command?
> > > > 
> > > > Best regards,
> > > > Diego Abelenda
> > > 
> > > Hi,
> > > 
> > > Do the other machines have a private address ? Is it a problem if they
> > > have one ? 
> > > If it is possible, you can route via this private address on your FreeBSD
> > > installation to the new one and assign a public/32 to the last.
> > > 
> > > Alternatively to doing routing like above, if you have a firewall enabled
> > > on the first machine, you can do address forwarding between the first and
> > > the new one. 
> > > 
> > > And last, maybe with something like -iface from "route" you can achieve
> > > what you want.   
> 



pgpIydq97MXm0.pgp
Description: OpenPGP digital signature

Re: IP "routing" issue

[John-Mark Gurney]

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:
> DestinationGateway   Flags Netif Expire
> default$UPSTREAM_GW  UGSbce0
> 10.0.0.1   link#7UHS lo0
> $IP_NO_IN_SUBNET   $MAC_ADDRESS_OF_BCE0  UHSbce0
> 
> 
> Which seem somehow appropriate, so I try to ping $IP_NOT_IN_SUBNET and I get:
> 
> root@opnsense2:~ # ping $IP_NOT_IN_SUBNET
> PING $IP_NOT_IN_SUBNET ($IP_NOT_IN_SUBNET): 56 data bytes
> 36 bytes from $UPSTREAM_GW: Redirect Host(New addr: $PUBLIC_IP_OF_BCE0).
> 
> Which doesn't seem appropriate at all wrt the routing table...
> 
> Did I use "route add" wrong?
> 
> Also I want to keep the setup simple, going through private IPs on the public 
> VLAN of the datacenter might get me in trouble with them, and using other 
> VLANs for that will be a pain.

Can you provide a diagram of the network layout, and where the
configuration needs to go?  Because if it's just the opnsense box that
needs the IP addresses, adding them as an alias to bce is enough to
make it work.

If you're trying to do something else, like have boxes behind the
opnsense box have those IP addresses, then:
route add $IP_NO_IN_SUBNET $IP_OF_BOX_WITH_IP_NO_IN_SUBNET

would just work.

I just noticed the 10.0.0.1 IP on lo0, and that's a bit odd to have...

> On Wed, 9 Sep 2020 17:35:45 +0200
> kaycee gb  wrote:
> 
> > 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
> > > Masquerading an private infrastructure.
> > > 
> > > Now I need other machines with public IPv4 and when I requested the
> > > additional IPv4 to the DataCenter, they gave me a bunch of /32 addresses
> > > saying that my previous IPv4 MUST be configured as next-hop on their side.
> > > 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 know the linux "ip route add $IP 
> > > dev
> > > $LINK" configures this, but I cannot seem to map this knowledge to 
> > > FreeBSD.
> > > 
> > > Is it possible to perform this very special setup with any command on
> > > FreeBSD? If yes what is that command?
> > > 
> > > Best regards,
> > > Diego Abelenda  
> > 
> > Hi,
> > 
> > Do the other machines have a private address ? Is it a problem if they have
> > one ? 
> > If it is possible, you can route via this private address on your FreeBSD
> > installation to the new one and assign a public/32 to the last.
> > 
> > Alternatively to doing routing like above, if you have a firewall enabled on
> > the first machine, you can do address forwarding between the first and the
> > new one. 
> > 
> > And last, maybe with something like -iface from "route" you can achieve what
> > you want. 

-- 
  John-Mark Gurney  Voice: +1 415 225 5579

 "All that I will do, has been done, All that I have, has not."


signature.asc
Description: PGP signature

Re: IP "routing" issue

[Eugene Grosbein]

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   Flags Netif Expire
> default$UPSTREAM_GW  UGSbce0
> 10.0.0.1   link#7UHS lo0
> $IP_NO_IN_SUBNET   $MAC_ADDRESS_OF_BCE0  UHSbce0
> 
> 
> Which seem somehow appropriate, so I try to ping $IP_NOT_IN_SUBNET and I get:
> 
> root@opnsense2:~ # ping $IP_NOT_IN_SUBNET
> PING $IP_NOT_IN_SUBNET ($IP_NOT_IN_SUBNET): 56 data bytes
> 36 bytes from $UPSTREAM_GW: Redirect Host(New addr: $PUBLIC_IP_OF_BCE0).
> 
> Which doesn't seem appropriate at all wrt the routing table...

Such route means that an attempt to send any packet to the IP in question
results in broadcast ARP query for destination IP sent out of bce0.

It seems your upstream has arp proxy enabled, so it sends ARP reply with its 
MAC address
making your host send IP packet to $UPSTREAM_GW, but its routing table points 
back
to your $PUBLIC_IP_OF_BCE0, hence redirection is generated.

You should not use "-iface bce0" but right interface name pointing to host 
having target IP address.
And if your own host has it, you do not need to add any route at all,
but assign additional IP as alias to bce0.
 
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: IP "routing" issue

[Abelenda Diego]

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_GW  UGSbce0
10.0.0.1   link#7UHS lo0
$IP_NO_IN_SUBNET   $MAC_ADDRESS_OF_BCE0  UHSbce0


Which seem somehow appropriate, so I try to ping $IP_NOT_IN_SUBNET and I get:

root@opnsense2:~ # ping $IP_NOT_IN_SUBNET
PING $IP_NOT_IN_SUBNET ($IP_NOT_IN_SUBNET): 56 data bytes
36 bytes from $UPSTREAM_GW: Redirect Host(New addr: $PUBLIC_IP_OF_BCE0).

Which doesn't seem appropriate at all wrt the routing table...

Did I use "route add" wrong?

Also I want to keep the setup simple, going through private IPs on the public 
VLAN of the datacenter might get me in trouble with them, and using other VLANs 
for that will be a pain.

Best regards,
Diego Abelenda


On Wed, 9 Sep 2020 17:35:45 +0200
kaycee gb  wrote:

> 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
> > Masquerading an private infrastructure.
> > 
> > Now I need other machines with public IPv4 and when I requested the
> > additional IPv4 to the DataCenter, they gave me a bunch of /32 addresses
> > saying that my previous IPv4 MUST be configured as next-hop on their side.
> > 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 know the linux "ip route add $IP dev
> > $LINK" configures this, but I cannot seem to map this knowledge to FreeBSD.
> > 
> > Is it possible to perform this very special setup with any command on
> > FreeBSD? If yes what is that command?
> > 
> > Best regards,
> > Diego Abelenda  
> 
> Hi,
> 
> Do the other machines have a private address ? Is it a problem if they have
> one ? 
> If it is possible, you can route via this private address on your FreeBSD
> installation to the new one and assign a public/32 to the last.
> 
> Alternatively to doing routing like above, if you have a firewall enabled on
> the first machine, you can do address forwarding between the first and the
> new one. 
> 
> And last, maybe with something like -iface from "route" you can achieve what
> you want. 
> 
> K.
> ___
> freebsd-net@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"



pgp160I9Yaio2.pgp
Description: OpenPGP digital signature

Re: IP "routing" issue

[Eugene Grosbein]

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
> infrastructure.
> 
> Now I need other machines with public IPv4 and when I requested the additional
> IPv4 to the DataCenter, they gave me a bunch of /32 addresses saying that
> my previous IPv4 MUST be configured as next-hop on their side.
> 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 know the linux "ip route add $IP dev
> $LINK" configures this, but I cannot seem to map this knowledge to FreeBSD.
> 
> Is it possible to perform this very special setup with any command on FreeBSD?
> If yes what is that command?

This setup is not special and FreeBSD can do it, of course.

route add 1.1.1.1/32 2.2.2.2
route add 1.1.2.1/32 -iface vtnet0

In this example 2.2.2.2 plays role of your old public IP and 1.1.X.X are for 
new addresses
routed via 2.2.2.2 or directly to interface vtnet0. And there is rc.conf 
settings "static_routes" to create such setup:

static_routes="host1 host2 host3"
route_host1="1.1.1.1/32 2.2.2.2"
route_host2="1.1.2.1/32 -iface vtnet0"

This is documented with route(8) and rc.conf(5) manual pages.

In case of P2P interface such variants have no real difference other than
used way to specify outgoing interface: by next-hop address or by interface 
name.
P2P interface may have no address assigned for remote side.

In case of Ethernet-link interface the difference is related to underlying ARP 
protocol cache,
will it be asked for MAC address of specified next-hop or directly for MAC 
address of target like 1.1.2.1.


___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: IP "routing" issue

[kaycee gb]

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 Masquerading an
> private infrastructure.
> 
> Now I need other machines with public IPv4 and when I requested the additional
> IPv4 to the DataCenter, they gave me a bunch of /32 addresses saying that
> my previous IPv4 MUST be configured as next-hop on their side.
> 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 know the linux "ip route add $IP dev
> $LINK" configures this, but I cannot seem to map this knowledge to FreeBSD.
> 
> Is it possible to perform this very special setup with any command on FreeBSD?
> If yes what is that command?
> 
> Best regards,
> Diego Abelenda

Hi,

Do the other machines have a private address ? Is it a problem if they have one
? 
If it is possible, you can route via this private address on your FreeBSD
installation to the new one and assign a public/32 to the last.

Alternatively to doing routing like above, if you have a firewall enabled on the
first machine, you can do address forwarding between the first and the new one. 

And last, maybe with something like -iface from "route" you can achieve what
you want. 

K.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: IP "routing" issue

[Abelenda Diego]

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 that I read the man, tried quite a few things with the
"route" command and could not get anything out of it.

Best regards,
Diego Abelenda


On Wed, 9 Sep 2020 11:48:58 -0300
Cristian Cardoso  wrote:

> 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 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 public IPv4 and when I requested the
> > additional IPv4 to the DataCenter, they gave me a bunch of /32 addresses
> > saying that my previous IPv4 MUST be configured as next-hop on their side.
> > 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 know the linux "ip route add $IP dev
> > $LINK" configures this, but I cannot seem to map this knowledge to FreeBSD.
> >
> > Is it possible to perform this very special setup with any command on
> > FreeBSD? If yes what is that command?
> >
> > Best regards,
> > Diego Abelenda  



pgp1IPXqHWPpk.pgp
Description: OpenPGP digital signature

Re: IP "routing" issue

[Cristian Cardoso]

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 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 public IPv4 and when I requested the additional
> IPv4 to the DataCenter, they gave me a bunch of /32 addresses saying that
> my previous IPv4 MUST be configured as next-hop on their side.
> 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 know the linux "ip route add $IP dev
> $LINK" configures this, but I cannot seem to map this knowledge to FreeBSD.
>
> Is it possible to perform this very special setup with any command on FreeBSD?
> If yes what is that command?
>
> Best regards,
> Diego Abelenda
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

IP "routing" issue

[Abelenda Diego]

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 public IPv4 and when I requested the additional
IPv4 to the DataCenter, they gave me a bunch of /32 addresses saying that
my previous IPv4 MUST be configured as next-hop on their side.
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 know the linux "ip route add $IP dev
$LINK" configures this, but I cannot seem to map this knowledge to FreeBSD.

Is it possible to perform this very special setup with any command on FreeBSD?
If yes what is that command?

Best regards,
Diego Abelenda


pgpE8UJnpiooh.pgp
Description: OpenPGP digital signature

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

[sepherosa_gmail.com (Sepherosa Ziehau)]

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, gnn, hiren, rwatson, 
karels, glebius
Cc: hrs, freebsd-net-list
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

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

[glebius (Gleb Smirnoff)]

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 and at the same time don't implicitly 
bring the interface up. The problem get worse when you add CARP into the mix.
  
  For the sake of historical behavior preservation, I would prefer to see hacks 
to ifconfig(8) rather than to in_control(). Ifconfig could issue SIOCSIFFLAGS 
after SIOCAIFADDR for the sake of compatibility.
  
  In the projects/ifnet branch this all is somewhat resolved. The only place 
that writes IFF_UP is if_up() and drivers aren't allowed to do that. The 
if_init method disappears and logic of initing and assigning address is split. 
You may look into that branch.

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, gnn, hiren, rwatson, 
karels, glebius
Cc: hrs, freebsd-net-list
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

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

[sepherosa_gmail.com (Sepherosa Ziehau)]

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 "down" is removing the route?  That seems 
wrong to me.
  
  
  IMHO, it's mainly because the radix tree only uses the target address to do 
the search.  So if you don't remove the prefix routes when bringing down the 
interface, radix search will end up w/ the route w/ a stopped interface; 
callers of the radix search don't have options to change this behaviour.
  
  If we don't delete the prefix routes if the interface is down, the following 
senario will not work:
  
GW --- NET_A --- if0 HOST1
 |if1
 | |
 + NET_B --+
  
  Given HOST1's default gwy is GW.  If if1 is brought down, but the NET_B's 
prefix route is not deleted, HOST1 will not be able to reach NET_B anymore, 
since the radix search always ends up w/ the route backed by if1.

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, gnn, hiren, glebius, 
rwatson, karels
Cc: hrs, freebsd-net-list
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

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

[karels (Mike Karels)]

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://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, gnn, hiren, glebius, 
rwatson, karels
Cc: hrs, freebsd-net-list
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[SOLVED] IPSec tunnel, VNET jail and routing issue

[Michael Grimm]

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/2410.2.2.0/24 any -P out ipsec 
> esp/tunnel/1.2.3.4-10.20.30.40/require;

Contrarily to this example line above, my real setkey.conf has had an "in" 
instead of "out" :-( 

> Achieved sofar:
> 
>   #) Allowing arpproxy_all="YES" will satisfy ARP (MACs from opposite 
> VNET jails will become assigned). 
>I do not know if that is needed, but now ping from jails to the 
> opposite jails will at least start to send ICMP packages.

Now I have to state: yes, ARP proxying is mandatory in my setup.

Hmm, I need to learn more about ARP. Because now I do observe a lot of lines 
like …

|  mike kernel: arp: proxy: ignoring request from 10.1.1.1 
via epair1a

… and I do not know if I do have to be concerned about those. Do I?


Sorry for the noise!

Regards,
Michael

___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

IPSec tunnel, VNET jail and routing issue

[Michael Grimm]

Hi --

I am referring to the following (simplified) setup:

[hostA /ix0 / 2001:dead::1 / 1.2.3.4] <= IPsec tunnel => [hostB / ix0 / 
2001:beef::10 / 10.20.30.40]
   || 
   ||
[jail1 / bridge0 / fd00:a::1 / 10.1.1.1] [jail1 / 
bridge0 / fd00:b::2 / 10.2.2.2]

All my jails are VNET jails, that use the bridge0 (epair) device. Thus, all 
IPv4 and IPv6 addresses of my local networks an A and B are bound to the 
bridge0 interface! But, the IPsec tunnel (via racoon) is anchored at public 
IPv4 addresses on ix0 at both hosts.

Task:
route all local traffic from hostA to hostB via the tunnel.

Working:
IPv6 traffic is running fine, meaning, that I can reach every jail from 
every host. That has been working for years.

Issue:
I recently wanted to extend my setup to local IPv4 addresses of my 
jails, and failed miserably.

Configuration (shown for hostA, only):

setkey.conf
#  hostA  hostB 
  hostA   hostB 
spdadd fd00:a::/64fd00:b::/64 any -P out ipsec 
esp/tunnel/1.2.3.4-10.20.30.40/require;
spdadd fd00:a::/642001:beef::/56  any -P out ipsec 
esp/tunnel/1.2.3.4-10.20.30.40/require;
spdadd 2001:dead::/56 fd00:b::/64 any -P out ipsec 
esp/tunnel/1.2.3.4-10.20.30.40/require;
#  hostB  hostA 
  hostB   hostA 
spdadd fd00:b::/64fd00:a::/64 any -P in  ipsec 
esp/tunnel/10.20.30.40-1.2.3.4/require;
spdadd fd00:b::/642001:dead::/56  any -P in  ipsec 
esp/tunnel/10.20.30.40-1.2.3.4/require;
spdadd 2001:beef::/56 fd00:a::/64 any -P in  ipsec 
esp/tunnel/10.20.30.40-1.2.3.4/require;
#  hostA  hostB 
  hostA   hostB 
spdadd 10.1.1.0/2410.2.2.0/24 any -P out ipsec 
esp/tunnel/1.2.3.4-10.20.30.40/require;
spdadd 10.1.1.0/2410.20.30.40 any -P out ipsec 
esp/tunnel/1.2.3.4-10.20.30.40/require;
spdadd 1.2.3.410.2.2.0/24 any -P out ipsec 
esp/tunnel/1.2.3.4-10.20.30.40/require;
#  hostB  hostA 
  hostB   hostA 
spdadd 10.2.2.0/2410.1.1.0/24 any -P in  ipsec 
esp/tunnel/10.20.30.40-1.2.3.4/require;
spdadd 10.2.2.0/241.2.3.4 any -P in  ipsec 
esp/tunnel/10.20.30.40-1.2.3.4/require;
spdadd 10.20.30.4010.1.1.0/24 any -P in  ipsec 
esp/tunnel/10.20.30.40-1.2.3.4/require;

There is no specific routing regarding the tunnel defined. All should 
be done by this spdadd's.

Achieved sofar:

#) I can reach each jail at the other site from the host.

#) Allowing arpproxy_all="YES" will satisfy ARP (MACs from opposite 
VNET jails will become assigned). 
   I do not know if that is needed, but now ping from jails to the 
opposite jails will at least start to send ICMP packages.

Unsolved issue:

I cannot reach opposite jails from another host's jail; e.g.: ping 
10.20.30.40 in jail1@hostA will not work.

Observations so far:

#) tcpdump shows for "ping 10.2.2.2 in jail1@hostA" ICMP traffic at the 
bridge0 at hostA:
IP 10.1.1.1 > 10.2.2.2: ICMP echo request, id 20099, seq 0, 
length 64 
   and at bridge0 at hostB:
IP 10.1.1.1 > 10.2.2.2: ICMP echo request, id 15233, seq 6, 
length 64 
IP 10.2.2.2 > 10.1.1.1: ICMP echo reply, id 15233, seq 6, 
length 64 

Hmm: hostA doesn't get an echo replay, although hostB did send one. 

#) tcpdump shows for "ping 10.2.2.2 at hostA" *no* ICMP traffic at 
hostA@bridge0 or hostA@ix0 but ICMP traffic at hostB@bridge0:
IP 1.2.3.4 > 10.2.2.2: ICMP echo request, id 60543, seq 0, 
length 64 
IP 10.2.2.2 > 1.2.3.4: ICMP echo reply, id 60543, seq 0, length 
64 

Hmm: it's working.

#) It looks to me as if the tunnel does not recognise "spdadd 
10.1.1.0/24 10.2.2.0/24" and vice versa settings because those IPs are bound to 
the 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?
#) Is this a routing issue?
#) Why does IPv6 address space work (identical configuration regarding 
jails, firewalling, routing, et al.)
#) Any other idea?

S

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

[sepherosa_gmail.com (Sepherosa Ziehau)]

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 SIOCAIFADDR.  Just calling 
if_up(ifp) looks too heavy to me because it causes extra pr_ctlinput() calls of 
each protocol, not only inetdomain, in order to recover the routes.  What do 
you think about adding reinstalltion of the prefix routes in the protocol 
specific PRC_IFUP handler instead?
  
  
  Well, I believe it mirrors the behavior of 'ifconfig iface0 up'; w/o the 
if_up(), we just bring the interface up w/o notifying any domains, which 
probably is not intended.

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, gnn, hiren, glebius, 
rwatson, karels
Cc: hrs, freebsd-net-list
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

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

[hrs (Hiroki Sato)]

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 pr_ctlinput() calls of 
each protocol, not only inetdomain, in order to recover the routes.  What do 
you think about adding reinstalltion of the prefix routes in the protocol 
specific PRC_IFUP handler instead?

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, gnn, hiren, glebius, 
rwatson, karels
Cc: hrs, freebsd-net-list
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

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

[sepherosa_gmail.com (Sepherosa Ziehau)]

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 is mainly intended to fix the following case at least:

ifconfig iface0 192.168.5.1
ifconfig iface0 down
ifconfig iface0 alias 192.168.6.1

Before this commit, the related part of the routing table is:
192.168.5.1link#3 UHS lo0
192.168.6.0/24 link#3 U   hn1
192.168.6.1link#3 UHS lo0

The 192.168.5.0/24 can't be reached.

After this fix, the related part of the routing table is:
192.168.5.0/24 link#3 U   hn1
192.168.5.1link#3 UHS lo0
192.168.6.0/24 link#3 U   hn1
192.168.6.1link#3 UHS lo0

Everything works as expected.

REVISION DETAIL
  https://reviews.freebsd.org/D8904

AFFECTED FILES
  sys/netinet/in.c

CHANGE DETAILS

diff --git a/sys/netinet/in.c b/sys/netinet/in.c
--- a/sys/netinet/in.c
+++ b/sys/netinet/in.c
@@ -228,7 +228,7 @@
struct sockaddr_in *addr = (struct sockaddr_in *)>ifr_addr;
struct ifaddr *ifa;
struct in_ifaddr *ia;
-   int error;
+   int error, was_up = 0;
 
if (ifp == NULL)
return (EADDRNOTAVAIL);
@@ -250,9 +250,13 @@
return (error);
case OSIOCAIFADDR:  /* 9.x compat */
case SIOCAIFADDR:
+   if (ifp->if_flags & IFF_UP)
+   was_up = 1;
sx_xlock(_control_sx);
error = in_aifaddr_ioctl(cmd, data, ifp, td);
sx_xunlock(_control_sx);
+   if (!was_up && (ifp->if_flags & IFF_UP))
+   if_up(ifp);
return (error);
case SIOCSIFADDR:
case SIOCSIFBRDADDR:



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, gnn, hiren, glebius, 
rwatson, karels
Cc: freebsd-net-list
diff --git a/sys/netinet/in.c b/sys/netinet/in.c
--- a/sys/netinet/in.c
+++ b/sys/netinet/in.c
@@ -228,7 +228,7 @@
 	struct sockaddr_in *addr = (struct sockaddr_in *)>ifr_addr;
 	struct ifaddr *ifa;
 	struct in_ifaddr *ia;
-	int error;
+	int error, was_up = 0;
 
 	if (ifp == NULL)
 		return (EADDRNOTAVAIL);
@@ -250,9 +250,13 @@
 		return (error);
 	case OSIOCAIFADDR:	/* 9.x compat */
 	case SIOCAIFADDR:
+		if (ifp->if_flags & IFF_UP)
+			was_up = 1;
 		sx_xlock(_control_sx);
 		error = in_aifaddr_ioctl(cmd, data, ifp, td);
 		sx_xunlock(_control_sx);
+		if (!was_up && (ifp->if_flags & IFF_UP))
+			if_up(ifp);
 		return (error);
 	case SIOCSIFADDR:
 	case SIOCSIFBRDADDR:

___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

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

[bugzilla-noreply]

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 receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: routing issue

[Pakhom Golynga]

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=4209b 


ether 00:25:90:64:14:50
inet 172.27.27.254 netmask 0xff00 broadcast 172.27.27.255
inet 172.27.27.240 netmask 0x broadcast 172.27.27.240
inet 172.27.27.252 netmask 0x broadcast 172.27.27.252
inet 172.27.27.251 netmask 0x broadcast 172.27.27.251
inet 172.27.27.250 netmask 0x broadcast 172.27.27.250
inet 172.27.27.249 netmask 0x broadcast 172.27.27.249
inet 172.27.27.248 netmask 0x broadcast 172.27.27.248
inet 172.27.27.247 netmask 0x broadcast 172.27.27.247
inet 172.27.27.246 netmask 0x broadcast 172.27.27.246
inet 172.27.27.245 netmask 0x broadcast 172.27.27.245
inet 172.27.27.244 netmask 0x broadcast 172.27.27.244
inet 172.27.27.243 netmask 0x broadcast 172.27.27.243
inet 172.27.27.242 netmask 0x broadcast 172.27.27.242
inet 172.27.27.241 netmask 0x broadcast 172.27.27.241
inet 172.27.27.239 netmask 0x broadcast 172.27.27.239
inet 172.27.27.238 netmask 0x broadcast 172.27.27.238
inet 172.27.27.237 netmask 0x broadcast 172.27.27.237
inet 172.27.27.236 netmask 0x broadcast 172.27.27.236
inet 172.27.27.235 netmask 0x broadcast 172.27.27.235
media: Ethernet autoselect (1000baseT )
status: active
em1: flags=8943 
metric 0 mtu 1500
options=4209b 


ether 00:25:90:64:14:51
inet 10.24.44.50 netmask 0xfc00 broadcast 10.24.47.255
media: Ethernet autoselect (100baseTX )
status: active
<--cut-->

em0 - local network. Aliases on em0 for Jail's
em1 - connected to ISP

This configuration successfully operate a long time but recently (for 
no apparent reason) suddenly became manifest bug with routing.
Regardless from uptime (sometimes 12 hours, and maybe a couple of 
days) after a certain time the traffic running between jails begins 
to route via em1 (instead lo0 (net.link.ether.inet.useloopback=1)):


this sounds much like another report we have seen.
you may be able to fix it by re-adding your routes..

The report  I have seen suggested that some routes seem to stop being 
effective after some period.

It's  still not understood.



Can I help with it? The issue is often reproduce on my system.



# tcpdump -n -e -ttt -i em1 host 172.27.27.252 or host 172.27.27.247 
or host 172.27.27.248
00:00:00.054989 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype IPv4 
(0x0800), length 74: 172.27.27.247.24868 > 172.27.27.252.25: Flags 
[S], seq 2075254199, win 65535, options [mss 16344,nop,wscale 
6,sackOK,TS val 161568673 ecr 0], length 0
00:00:00.318036 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype IPv4 
(0x0800), length 66: 172.27.27.247.80 > 172.27.27.248.60176: Flags 
[.], ack 772660872, win 1275, options [nop,nop,TS val 1737287913 ecr 
161568991], length 0
00:00:00.036971 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype IPv4 
(0x0800), length 66: 172.27.27.247.80 > 172.27.27.248.33080: Flags 
[.], ack 1, win 1275, options [nop,nop,TS val 1701623130 ecr 
161568238], length 0
00:00:00.050001 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype IPv4 
(0x0800), length 66: 172.27.27.247.80 > 172.27.27.248.40200: Flags 
[.], ack 1, win 1275, options [nop,nop,TS val 1477098721 ecr 
161568288], length 0
00:00:02.794992 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype IPv4 
(0x0800), length 74: 172.27.27.247.24868 > 172.27.27.252.25: Flags 
[S], seq 2075254199, win 65535, options [mss 16344,nop,wscale 
6,sackOK,TS val 161571873 ecr 0], length 0
00:00:03.312026 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype IPv4 
(0x0800), length 74: 172.27.27.247.29581 > 172.27.27.252.25: Flags 
[S], seq 1217253021, win 65535, options [mss 16344,nop,wscale 
6,sackOK,TS val 161575185 ecr 0], length 0
00:00:02.887982 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype IPv4 
(0x0800), length 74: 172.27.27.247.24868 > 172.27.27.252.25: Flags 
[S], seq 2075254199, win 65535, options [mss 16344,nop,wscale 
6,sackOK,TS val 161578073 ecr 0], length 0
00:00:00.111989 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype IPv4 
(0x0800), length 74: 172.27.27.247.29581 > 172.27.27.252.25: Flags 
[S], seq 1217253021, win 65535, options [mss 16344,nop,wscale 
6,sackOK,TS val 161578185 ecr 0], length 0
00:00:03.471007 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype IPv4 
(0x0800), length 

Re: routing issue

[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=4209b 


ether 00:25:90:64:14:50
inet 172.27.27.254 netmask 0xff00 broadcast 172.27.27.255
inet 172.27.27.240 netmask 0x broadcast 172.27.27.240
inet 172.27.27.252 netmask 0x broadcast 172.27.27.252
inet 172.27.27.251 netmask 0x broadcast 172.27.27.251
inet 172.27.27.250 netmask 0x broadcast 172.27.27.250
inet 172.27.27.249 netmask 0x broadcast 172.27.27.249
inet 172.27.27.248 netmask 0x broadcast 172.27.27.248
inet 172.27.27.247 netmask 0x broadcast 172.27.27.247
inet 172.27.27.246 netmask 0x broadcast 172.27.27.246
inet 172.27.27.245 netmask 0x broadcast 172.27.27.245
inet 172.27.27.244 netmask 0x broadcast 172.27.27.244
inet 172.27.27.243 netmask 0x broadcast 172.27.27.243
inet 172.27.27.242 netmask 0x broadcast 172.27.27.242
inet 172.27.27.241 netmask 0x broadcast 172.27.27.241
inet 172.27.27.239 netmask 0x broadcast 172.27.27.239
inet 172.27.27.238 netmask 0x broadcast 172.27.27.238
inet 172.27.27.237 netmask 0x broadcast 172.27.27.237
inet 172.27.27.236 netmask 0x broadcast 172.27.27.236
inet 172.27.27.235 netmask 0x broadcast 172.27.27.235
media: Ethernet autoselect (1000baseT )
status: active
em1: flags=8943 
metric 0 mtu 1500
options=4209b 


ether 00:25:90:64:14:51
inet 10.24.44.50 netmask 0xfc00 broadcast 10.24.47.255
media: Ethernet autoselect (100baseTX )
status: active
<--cut-->

em0 - local network. Aliases on em0 for Jail's
em1 - connected to ISP

This configuration successfully operate a long time but recently 
(for no apparent reason) suddenly became manifest bug with routing.
Regardless from uptime (sometimes 12 hours, and maybe a couple of 
days) after a certain time the traffic running between jails begins 
to route via em1 (instead lo0 (net.link.ether.inet.useloopback=1)):


this sounds much like another report we have seen.
you may be able to fix it by re-adding your routes..

The report  I have seen suggested that some routes seem to stop being 
effective after some period.

It's  still not understood.


# tcpdump -n -e -ttt -i em1 host 172.27.27.252 or host 172.27.27.247 
or host 172.27.27.248
00:00:00.054989 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype 
IPv4 (0x0800), length 74: 172.27.27.247.24868 > 172.27.27.252.25: 
Flags [S], seq 2075254199, win 65535, options [mss 16344,nop,wscale 
6,sackOK,TS val 161568673 ecr 0], length 0
00:00:00.318036 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype 
IPv4 (0x0800), length 66: 172.27.27.247.80 > 172.27.27.248.60176: 
Flags [.], ack 772660872, win 1275, options [nop,nop,TS val 
1737287913 ecr 161568991], length 0
00:00:00.036971 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype 
IPv4 (0x0800), length 66: 172.27.27.247.80 > 172.27.27.248.33080: 
Flags [.], ack 1, win 1275, options [nop,nop,TS val 1701623130 ecr 
161568238], length 0
00:00:00.050001 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype 
IPv4 (0x0800), length 66: 172.27.27.247.80 > 172.27.27.248.40200: 
Flags [.], ack 1, win 1275, options [nop,nop,TS val 1477098721 ecr 
161568288], length 0
00:00:02.794992 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype 
IPv4 (0x0800), length 74: 172.27.27.247.24868 > 172.27.27.252.25: 
Flags [S], seq 2075254199, win 65535, options [mss 16344,nop,wscale 
6,sackOK,TS val 161571873 ecr 0], length 0
00:00:03.312026 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype 
IPv4 (0x0800), length 74: 172.27.27.247.29581 > 172.27.27.252.25: 
Flags [S], seq 1217253021, win 65535, options [mss 16344,nop,wscale 
6,sackOK,TS val 161575185 ecr 0], length 0
00:00:02.887982 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype 
IPv4 (0x0800), length 74: 172.27.27.247.24868 > 172.27.27.252.25: 
Flags [S], seq 2075254199, win 65535, options [mss 16344,nop,wscale 
6,sackOK,TS val 161578073 ecr 0], length 0
00:00:00.111989 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype 
IPv4 (0x0800), length 74: 172.27.27.247.29581 > 172.27.27.252.25: 
Flags [S], seq 1217253021, win 65535, options [mss 16344,nop,wscale 
6,sackOK,TS val 161578185 ecr 0], length 0
00:00:03.471007 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype 
IPv4 (0x0800), length 108: 172.27.27.247.80 > 172.27.27.248.26056: 
Flags [FP.], seq 1448:1490, ack 1, win 1275, options [nop,nop,TS 

routing issue

[Pakhom Golynga]

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 broadcast 172.27.27.255
inet 172.27.27.240 netmask 0x broadcast 172.27.27.240
inet 172.27.27.252 netmask 0x broadcast 172.27.27.252
inet 172.27.27.251 netmask 0x broadcast 172.27.27.251
inet 172.27.27.250 netmask 0x broadcast 172.27.27.250
inet 172.27.27.249 netmask 0x broadcast 172.27.27.249
inet 172.27.27.248 netmask 0x broadcast 172.27.27.248
inet 172.27.27.247 netmask 0x broadcast 172.27.27.247
inet 172.27.27.246 netmask 0x broadcast 172.27.27.246
inet 172.27.27.245 netmask 0x broadcast 172.27.27.245
inet 172.27.27.244 netmask 0x broadcast 172.27.27.244
inet 172.27.27.243 netmask 0x broadcast 172.27.27.243
inet 172.27.27.242 netmask 0x broadcast 172.27.27.242
inet 172.27.27.241 netmask 0x broadcast 172.27.27.241
inet 172.27.27.239 netmask 0x broadcast 172.27.27.239
inet 172.27.27.238 netmask 0x broadcast 172.27.27.238
inet 172.27.27.237 netmask 0x broadcast 172.27.27.237
inet 172.27.27.236 netmask 0x broadcast 172.27.27.236
inet 172.27.27.235 netmask 0x broadcast 172.27.27.235
media: Ethernet autoselect (1000baseT )
status: active
em1: flags=8943 metric 0 
mtu 1500
options=4209b 


ether 00:25:90:64:14:51
inet 10.24.44.50 netmask 0xfc00 broadcast 10.24.47.255
media: Ethernet autoselect (100baseTX )
status: active
<--cut-->

em0 - local network. Aliases on em0 for Jail's
em1 - connected to ISP

This configuration successfully operate a long time but recently (for no 
apparent reason) suddenly became manifest bug with routing.
Regardless from uptime (sometimes 12 hours, and maybe a couple of days) 
after a certain time the traffic running between jails begins to route 
via em1 (instead lo0 (net.link.ether.inet.useloopback=1)):
# tcpdump -n -e -ttt -i em1 host 172.27.27.252 or host 172.27.27.247 or 
host 172.27.27.248
00:00:00.054989 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype IPv4 
(0x0800), length 74: 172.27.27.247.24868 > 172.27.27.252.25: Flags [S], 
seq 2075254199, win 65535, options [mss 16344,nop,wscale 6,sackOK,TS val 
161568673 ecr 0], length 0
00:00:00.318036 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype IPv4 
(0x0800), length 66: 172.27.27.247.80 > 172.27.27.248.60176: Flags [.], 
ack 772660872, win 1275, options [nop,nop,TS val 1737287913 ecr 
161568991], length 0
00:00:00.036971 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype IPv4 
(0x0800), length 66: 172.27.27.247.80 > 172.27.27.248.33080: Flags [.], 
ack 1, win 1275, options [nop,nop,TS val 1701623130 ecr 161568238], length 0
00:00:00.050001 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype IPv4 
(0x0800), length 66: 172.27.27.247.80 > 172.27.27.248.40200: Flags [.], 
ack 1, win 1275, options [nop,nop,TS val 1477098721 ecr 161568288], length 0
00:00:02.794992 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype IPv4 
(0x0800), length 74: 172.27.27.247.24868 > 172.27.27.252.25: Flags [S], 
seq 2075254199, win 65535, options [mss 16344,nop,wscale 6,sackOK,TS val 
161571873 ecr 0], length 0
00:00:03.312026 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype IPv4 
(0x0800), length 74: 172.27.27.247.29581 > 172.27.27.252.25: Flags [S], 
seq 1217253021, win 65535, options [mss 16344,nop,wscale 6,sackOK,TS val 
161575185 ecr 0], length 0
00:00:02.887982 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype IPv4 
(0x0800), length 74: 172.27.27.247.24868 > 172.27.27.252.25: Flags [S], 
seq 2075254199, win 65535, options [mss 16344,nop,wscale 6,sackOK,TS val 
161578073 ecr 0], length 0
00:00:00.111989 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype IPv4 
(0x0800), length 74: 172.27.27.247.29581 > 172.27.27.252.25: Flags [S], 
seq 1217253021, win 65535, options [mss 16344,nop,wscale 6,sackOK,TS val 
161578185 ecr 0], length 0
00:00:03.471007 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype IPv4 
(0x0800), length 108: 172.27.27.247.80 > 172.27.27.248.26056: Flags 
[FP.], seq 1448:1490, ack 1, win 1275, options [nop,nop,TS val 
2142270801 ecr 161575507], length 42


In the same time:
# route -vn get -host
RTA_DST: inet 172.27.27.247; RTA_IFP: link ; RTM_GET: Report Metrics: 
len 224, pid: 0, seq 1, errno 0, flags:

locks:  inits:
sockaddrs: 
 172.27.27.247 link#0
   route 

routing issue

[Pakhom Golynga]

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 broadcast 172.27.27.255
inet 172.27.27.240 netmask 0x broadcast 172.27.27.240
inet 172.27.27.252 netmask 0x broadcast 172.27.27.252
inet 172.27.27.251 netmask 0x broadcast 172.27.27.251
inet 172.27.27.250 netmask 0x broadcast 172.27.27.250
inet 172.27.27.249 netmask 0x broadcast 172.27.27.249
inet 172.27.27.248 netmask 0x broadcast 172.27.27.248
inet 172.27.27.247 netmask 0x broadcast 172.27.27.247
inet 172.27.27.246 netmask 0x broadcast 172.27.27.246
inet 172.27.27.245 netmask 0x broadcast 172.27.27.245
inet 172.27.27.244 netmask 0x broadcast 172.27.27.244
inet 172.27.27.243 netmask 0x broadcast 172.27.27.243
inet 172.27.27.242 netmask 0x broadcast 172.27.27.242
inet 172.27.27.241 netmask 0x broadcast 172.27.27.241
inet 172.27.27.239 netmask 0x broadcast 172.27.27.239
inet 172.27.27.238 netmask 0x broadcast 172.27.27.238
inet 172.27.27.237 netmask 0x broadcast 172.27.27.237
inet 172.27.27.236 netmask 0x broadcast 172.27.27.236
inet 172.27.27.235 netmask 0x broadcast 172.27.27.235
media: Ethernet autoselect (1000baseT )
status: active
em1: flags=8943 metric 0 
mtu 1500
options=4209b 


ether 00:25:90:64:14:51
inet 10.24.44.50 netmask 0xfc00 broadcast 10.24.47.255
media: Ethernet autoselect (100baseTX )
status: active
<--cut-->

em0 - local network. Aliases on em0 for Jail's
em1 - connected to ISP

This configuration successfully operate a long time but recently (for no 
apparent reason) suddenly became manifest bug with routing.
Regardless from uptime (sometimes 12 hours, and maybe a couple of days) 
after a certain time the traffic running between jails begins to route 
via em1 (instead lo0 (net.link.ether.inet.useloopback=1)):
# tcpdump -n -e -ttt -i em1 host 172.27.27.252 or host 172.27.27.247 or 
host 172.27.27.248
00:00:00.054989 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype IPv4 
(0x0800), length 74: 172.27.27.247.24868 > 172.27.27.252.25: Flags [S], 
seq 2075254199, win 65535, options [mss 16344,nop,wscale 6,sackOK,TS val 
161568673 ecr 0], length 0
00:00:00.318036 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype IPv4 
(0x0800), length 66: 172.27.27.247.80 > 172.27.27.248.60176: Flags [.], 
ack 772660872, win 1275, options [nop,nop,TS val 1737287913 ecr 
161568991], length 0
00:00:00.036971 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype IPv4 
(0x0800), length 66: 172.27.27.247.80 > 172.27.27.248.33080: Flags [.], 
ack 1, win 1275, options [nop,nop,TS val 1701623130 ecr 161568238], length 0
00:00:00.050001 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype IPv4 
(0x0800), length 66: 172.27.27.247.80 > 172.27.27.248.40200: Flags [.], 
ack 1, win 1275, options [nop,nop,TS val 1477098721 ecr 161568288], length 0
00:00:02.794992 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype IPv4 
(0x0800), length 74: 172.27.27.247.24868 > 172.27.27.252.25: Flags [S], 
seq 2075254199, win 65535, options [mss 16344,nop,wscale 6,sackOK,TS val 
161571873 ecr 0], length 0
00:00:03.312026 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype IPv4 
(0x0800), length 74: 172.27.27.247.29581 > 172.27.27.252.25: Flags [S], 
seq 1217253021, win 65535, options [mss 16344,nop,wscale 6,sackOK,TS val 
161575185 ecr 0], length 0
00:00:02.887982 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype IPv4 
(0x0800), length 74: 172.27.27.247.24868 > 172.27.27.252.25: Flags [S], 
seq 2075254199, win 65535, options [mss 16344,nop,wscale 6,sackOK,TS val 
161578073 ecr 0], length 0
00:00:00.111989 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype IPv4 
(0x0800), length 74: 172.27.27.247.29581 > 172.27.27.252.25: Flags [S], 
seq 1217253021, win 65535, options [mss 16344,nop,wscale 6,sackOK,TS val 
161578185 ecr 0], length 0
00:00:03.471007 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype IPv4 
(0x0800), length 108: 172.27.27.247.80 > 172.27.27.248.26056: Flags 
[FP.], seq 1448:1490, ack 1, win 1275, options [nop,nop,TS val 
2142270801 ecr 161575507], length 42


In the same time:
# route -vn get -host
RTA_DST: inet 172.27.27.247; RTA_IFP: link ; RTM_GET: Report Metrics: 
len 224, pid: 0, seq 1, errno 0, flags:

locks:  inits:
sockaddrs: 
 172.27.27.247 link#0
   route 

routing issue

[Pakhom Golynga]

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 broadcast 172.27.27.255
inet 172.27.27.240 netmask 0x broadcast 172.27.27.240
inet 172.27.27.252 netmask 0x broadcast 172.27.27.252
inet 172.27.27.251 netmask 0x broadcast 172.27.27.251
inet 172.27.27.250 netmask 0x broadcast 172.27.27.250
inet 172.27.27.249 netmask 0x broadcast 172.27.27.249
inet 172.27.27.248 netmask 0x broadcast 172.27.27.248
inet 172.27.27.247 netmask 0x broadcast 172.27.27.247
inet 172.27.27.246 netmask 0x broadcast 172.27.27.246
inet 172.27.27.245 netmask 0x broadcast 172.27.27.245
inet 172.27.27.244 netmask 0x broadcast 172.27.27.244
inet 172.27.27.243 netmask 0x broadcast 172.27.27.243
inet 172.27.27.242 netmask 0x broadcast 172.27.27.242
inet 172.27.27.241 netmask 0x broadcast 172.27.27.241
inet 172.27.27.239 netmask 0x broadcast 172.27.27.239
inet 172.27.27.238 netmask 0x broadcast 172.27.27.238
inet 172.27.27.237 netmask 0x broadcast 172.27.27.237
inet 172.27.27.236 netmask 0x broadcast 172.27.27.236
inet 172.27.27.235 netmask 0x broadcast 172.27.27.235
media: Ethernet autoselect (1000baseT )
status: active
em1: flags=8943 metric 0 
mtu 1500
options=4209b 


ether 00:25:90:64:14:51
inet 10.24.44.50 netmask 0xfc00 broadcast 10.24.47.255
media: Ethernet autoselect (100baseTX )
status: active
<--cut-->

em0 - local network. Aliases on em0 for Jail's
em1 - connected to ISP

This configuration successfully operate a long time but recently (for no 
apparent reason) suddenly became manifest bug with routing.
Regardless from uptime (sometimes 12 hours, and maybe a couple of days) 
after a certain time the traffic running between jails begins to route 
via em1 (instead lo0 (net.link.ether.inet.useloopback=1)):
# tcpdump -n -e -ttt -i em1 host 172.27.27.252 or host 172.27.27.247 or 
host 172.27.27.248
00:00:00.054989 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype IPv4 
(0x0800), length 74: 172.27.27.247.24868 > 172.27.27.252.25: Flags [S], 
seq 2075254199, win 65535, options [mss 16344,nop,wscale 6,sackOK,TS val 
161568673 ecr 0], length 0
00:00:00.318036 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype IPv4 
(0x0800), length 66: 172.27.27.247.80 > 172.27.27.248.60176: Flags [.], 
ack 772660872, win 1275, options [nop,nop,TS val 1737287913 ecr 
161568991], length 0
00:00:00.036971 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype IPv4 
(0x0800), length 66: 172.27.27.247.80 > 172.27.27.248.33080: Flags [.], 
ack 1, win 1275, options [nop,nop,TS val 1701623130 ecr 161568238], 
length 0
00:00:00.050001 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype IPv4 
(0x0800), length 66: 172.27.27.247.80 > 172.27.27.248.40200: Flags [.], 
ack 1, win 1275, options [nop,nop,TS val 1477098721 ecr 161568288], 
length 0
00:00:02.794992 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype IPv4 
(0x0800), length 74: 172.27.27.247.24868 > 172.27.27.252.25: Flags [S], 
seq 2075254199, win 65535, options [mss 16344,nop,wscale 6,sackOK,TS val 
161571873 ecr 0], length 0
00:00:03.312026 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype IPv4 
(0x0800), length 74: 172.27.27.247.29581 > 172.27.27.252.25: Flags [S], 
seq 1217253021, win 65535, options [mss 16344,nop,wscale 6,sackOK,TS val 
161575185 ecr 0], length 0
00:00:02.887982 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype IPv4 
(0x0800), length 74: 172.27.27.247.24868 > 172.27.27.252.25: Flags [S], 
seq 2075254199, win 65535, options [mss 16344,nop,wscale 6,sackOK,TS val 
161578073 ecr 0], length 0
00:00:00.111989 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype IPv4 
(0x0800), length 74: 172.27.27.247.29581 > 172.27.27.252.25: Flags [S], 
seq 1217253021, win 65535, options [mss 16344,nop,wscale 6,sackOK,TS val 
161578185 ecr 0], length 0
00:00:03.471007 00:25:90:64:14:51 > 68:bd:ab:5f:ea:d8, ethertype IPv4 
(0x0800), length 108: 172.27.27.247.80 > 172.27.27.248.26056: Flags 
[FP.], seq 1448:1490, ack 1, win 1275, options [nop,nop,TS val 
2142270801 ecr 161575507], length 42


In the same time:
# route -vn get -host
RTA_DST: inet 172.27.27.247; RTA_IFP: link ; RTM_GET: Report Metrics: 
len 224, pid: 0, seq 1, errno 0, flags:

locks:  inits:
sockaddrs: 
 172.27.27.247 link#0
   

Re: IPSEC MTU routing issue

[VANHULLEBUS Yvan]

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 to be
 working, icmp between networks is ok, you can successfully telnet on
 services on the other side. However when you need to transfer some
 data strange things happen. I'm really trying to wrap my head around
 it and I still don't understand why it happens
 (http://pastebin.com/NAspcM9w). The packets smaller than 1260 and
 larger than 1417 are delivered to vlan103, the ones in between are
 not.

I'm not sure why do you have this strange issue.
Having a look at your IPsec/ESP related kernel stats may give a first
idea.


But I know that, even if you find a fix for this, you'll have very
poor performances as soon as packets start to be fragmented, and your
data transferts may just stall forever.

So, the usual way of solving that is to change the TCPMSS low enough
on the fly for all IPsec related trafic.
1300 is a common value, low enough to avoid fragmentation, and high
enough to keep good throughput.

Of course, this will only works for TCP, but most big packets / long
flows are done on TCP.


Yvan.

 If anyone has any idea why this might happen please shed some light.
 
 # tcpdump -nttti gif0
 
 00:00:00.00 IP a.b.c.d  e.f.g.h: ICMP echo request, id
 21034, seq 1, length 1108
 00:00:43.603248 IP a.b.c.d  e.f.g.h: ICMP echo request, id
 22826, seq 1, length 1308
 
 # tcpdump -nttti enc0
 
 00:00:00.00 (authentic,confidential): SPI 0x0d06e35d: IP
 109.235.79.81  193.239.202.174: IP a.b.c.d  e.f.g.h: ICMP echo
 request, id 21034, seq 1, length 1108 (ipip-proto-4)
 00:00:00.000139 (authentic,confidential): SPI 0x86741d6b: IP
 e.f.g.h  a.b.c.d: ICMP echo reply, id 21034, seq 1, length 1108
 00:00:00.06 (authentic,confidential): SPI 0x86741d6b: IP
 193.239.202.174  109.235.79.81: IP e.f.g.h  a.b.c.d: ICMP echo
 reply, id 21034, seq 1, length 1108 (ipip-proto-4)
 00:00:43.603102 (authentic,confidential): SPI 0x0d06e35d: IP
 109.235.79.81  193.239.202.174: IP a.b.c.d  e.f.g.h: ICMP echo
 request, id 22826, seq 1, length 1308 (ipip-proto-4)
 
 # tcpdump -nttti vlan103 host a.b.c.d
 
 00:00:00.00 IP a.b.c.d  e.f.g.h: ICMP echo request, id
 21034, seq 1, length 1108
 00:00:00.000109 IP e.f.g.h  a.b.c.d: ICMP echo reply, id 21034,
 seq 1, length 1108
 
 Thanks,
 
 -- 
 Andrei
 ___
 freebsd-net@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-net
 To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

IPSEC MTU routing issue

[Andrei Brezan]

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 on services on 
the other side. However when you need to transfer some data strange 
things happen. I'm really trying to wrap my head around it and I still 
don't understand why it happens (http://pastebin.com/NAspcM9w). The 
packets smaller than 1260 and larger than 1417 are delivered to vlan103, 
the ones in between are not.


If anyone has any idea why this might happen please shed some light.

# tcpdump -nttti gif0

00:00:00.00 IP a.b.c.d  e.f.g.h: ICMP echo request, id 21034, 
seq 1, length 1108
00:00:43.603248 IP a.b.c.d  e.f.g.h: ICMP echo request, id 22826, 
seq 1, length 1308


# tcpdump -nttti enc0

00:00:00.00 (authentic,confidential): SPI 0x0d06e35d: IP 
109.235.79.81  193.239.202.174: IP a.b.c.d  e.f.g.h: ICMP echo 
request, id 21034, seq 1, length 1108 (ipip-proto-4)
00:00:00.000139 (authentic,confidential): SPI 0x86741d6b: IP e.f.g.h  
a.b.c.d: ICMP echo reply, id 21034, seq 1, length 1108
00:00:00.06 (authentic,confidential): SPI 0x86741d6b: IP 
193.239.202.174  109.235.79.81: IP e.f.g.h  a.b.c.d: ICMP echo 
reply, id 21034, seq 1, length 1108 (ipip-proto-4)
00:00:43.603102 (authentic,confidential): SPI 0x0d06e35d: IP 
109.235.79.81  193.239.202.174: IP a.b.c.d  e.f.g.h: ICMP echo 
request, id 22826, seq 1, length 1308 (ipip-proto-4)


# tcpdump -nttti vlan103 host a.b.c.d

00:00:00.00 IP a.b.c.d  e.f.g.h: ICMP echo request, id 21034, 
seq 1, length 1108
00:00:00.000109 IP e.f.g.h  a.b.c.d: ICMP echo reply, id 21034, seq 
1, length 1108


Thanks,

--
Andrei
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

Re: ipfw / routing issue on 9.2-RELEASE

[Andreas Nilsson]

On Wed, Mar 26, 2014 at 5:42 PM, Andreas Nilsson andrn...@gmail.com wrote:

  ... snip ...


 I'm wondering what's happening on the outbound path, most of your rules
 handle inbound (to kernel) and it seems that rule 65535 deals with most
 outbound, except those specifically acting on both paths.

 So do I :)


 Maybe try adding to the above:
 ipfw add 63510 count log ip from table(1) to any out recv table(8)
 and
 ipfw add 64510 count log ip from table(1) to any out recv table(8)

 which should catch them on the outbound path before the default rule;
 outbound packets have both receive and transmit interfaces available.

 They never get that far :( Those rules log nothing. So I see the packet
 coming in, triggering the skipto, triggering the count log ... in recv but
 not the count log ... out.


 I guess 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 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 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 that a reboot
 might help, but this is kind of fascinating so I would like to actually
 find the cause. I will investigate further.

 Best regards
 Andreas


 And now it happened on another machine, but different type of traffic.
 Traffic triggering the divert rule work fine, some traffic not triggering
 the divert rule does not. After everything works as expected.

 Before reboot I flushed the firewall so that only default rule was in play
 ( allow all from any to any ), and then *no* traffic for that destination
 went out of the box.

 There are something like ~1000 routes in the routing table. Routes are
 added and removed according to some triggers, so during uptime of the
 machine there is a bit of messing with the routing table. At this stage I'm
 at a loss on how to continue investigating this, so I'll just implement the
 forwarding via fwd rules in ipfw and altogether ignore the routing table.

 Best regards
 Andreas


Ok, found the culprit:

-# $FreeBSD: releng/9.1/etc/rc.d/netif 212579 2010-09-13 19:55:40Z hrs $

+# $FreeBSD: releng/9.2/etc/rc.d/netif 253238 2013-07-12 01:34:24Z hrs $

+ if [ -f /etc/rc.d/routing -a -n $cmdifn ] ; then

+ for _if in $cmdifn; do

+  /etc/rc.d/routing start any $_if

+ done
+ fi

etc/rc.d/routing enforces gateway_enable setting in rc.conf which does not
play well with setting net.inet.ip.forwarding=1 in sysctl.conf directly.
Very annoying.

I can find nothing i UPDATING on the subject. Even more annoying.

Best regards
Andreas
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

Re: ipfw / routing issue on 9.2-RELEASE

[Andreas Nilsson]

 ... snip ...


 I'm wondering what's happening on the outbound path, most of your rules
 handle inbound (to kernel) and it seems that rule 65535 deals with most
 outbound, except those specifically acting on both paths.

 So do I :)


 Maybe try adding to the above:
 ipfw add 63510 count log ip from table(1) to any out recv table(8)
 and
 ipfw add 64510 count log ip from table(1) to any out recv table(8)

 which should catch them on the outbound path before the default rule;
 outbound packets have both receive and transmit interfaces available.

 They never get that far :( Those rules log nothing. So I see the packet
 coming in, triggering the skipto, triggering the count log ... in recv but
 not the count log ... out.


 I guess 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 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 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 that a reboot might
 help, but this is kind of fascinating so I would like to actually find the
 cause. I will investigate further.

 Best regards
 Andreas


And now it happened on another machine, but different type of traffic.
Traffic triggering the divert rule work fine, some traffic not triggering
the divert rule does not. After everything works as expected.

Before reboot I flushed the firewall so that only default rule was in play
( allow all from any to any ), and then *no* traffic for that destination
went out of the box.

There are something like ~1000 routes in the routing table. Routes are
added and removed according to some triggers, so during uptime of the
machine there is a bit of messing with the routing table. At this stage I'm
at a loss on how to continue investigating this, so I'll just implement the
forwarding via fwd rules in ipfw and altogether ignore the routing table.

Best regards
Andreas
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

Re: ipfw / routing issue on 9.2-RELEASE

[Andreas Nilsson]

... snip ...


 Ah.  Well it was good to see the rules listed anyway, always helps.

   Was the count rules something like:
  
   1 901  46132 skipto 63000 ip from table(1) to any in recv
   table(8)
  
   ... same as before ...
  
   63500 895  45844 count log logamount 100 ip from table(1) to
 any in
   recv table(8)
  
   64000   0  0 fwd tablearg ip from table(12) to any
  
   64500 895  45844 count log logamount 100 ip from table(1) to
 any in
   recv table(8)
   65535 3849164 1234591611 allow ip from any to any
  
   So everything looks nice enough, but still no go. Interestingly enough,
   since this is a production machine I can't fool around to much ( that's
 why
   it took a while to get the above results ) I tried to reproduce this on
   another machine. Lo and behold, I couldn't. There it worked with the
   skipto-version. I'll investigate this and see if I can find any
 differences.

 I'm wondering what's happening on the outbound path, most of your rules
 handle inbound (to kernel) and it seems that rule 65535 deals with most
 outbound, except those specifically acting on both paths.

So do I :)


 Maybe try adding to the above:
 ipfw add 63510 count log ip from table(1) to any out recv table(8)
 and
 ipfw add 64510 count log ip from table(1) to any out recv table(8)

 which should catch them on the outbound path before the default rule;
 outbound packets have both receive and transmit interfaces available.

 They never get that far :( Those rules log nothing. So I see the packet
coming in, triggering the skipto, triggering the count log ... in recv but
not the count log ... out.


 I guess 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 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 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 that a reboot might
help, but this is kind of fascinating so I would like to actually find the
cause. I will investigate further.

Best regards
Andreas
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

Re: ipfw / routing issue on 9.2-RELEASE

[Raimundo Santos]

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, 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 add 65534 fwd tablearg all from table(12) to any

 Table 1 contains prefixes that should skip the normal rules and just pass
 through the box.

 Table 8 contains interface names.

 Table 12 is empty (so far).

 What happens is that packets that trigger the first rule never get to their
 destination. After looking at /var/log/security is see that packets trigger
 the rule, never to be seen again. There is a route (ie not default) for
 the destination, but a tcpdump on the corresponding interface shows
 nothing.


 On changing the ruleset to
 $cmd=ipfw -fq 

 $cmd add 1 skipto 65533 log all from table(1) to any in recv table(8)

 ...

 $cmd add 65533 fwd x.y.z.w ip from table(1) to any in recv table(8)

 $cmd add 65534 fwd tablearg all from table(12) to any

 packets get to where they should.


 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 intact. Why does the kernel not forward those
 packets?


 Best regards

 Andreas Nilsson
 ___
 freebsd-net@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-net
 To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

Re: ipfw / routing issue on 9.2-RELEASE

[Andreas Nilsson]

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 packets. Other packets on the box that
traverse the ruleset goes out just fine.


 Best regards,
 Raimundo




___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

Re: ipfw / routing issue on 9.2-RELEASE

[Andrey V. Elsukov]

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 intact. Why does the kernel not forward those
 packets?

What is the last rule? I suspect it is deny all?

-- 
WBR, Andrey V. Elsukov
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

Re: ipfw / routing issue on 9.2-RELEASE

[Andreas Nilsson]

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 triggers on the same thing as the skipto rule it would
  seem like packets are intact. Why does the kernel not forward those
  packets?

 What is the last rule? I suspect it is deny all?


No, last rule is allow any from any set via loader tunable
net.inet.ip.fw.default_to_accept=1

For clarity :

10  0 skipto 65534 log all from table(1) to any in recv
table(8)

2  6331546  601809038 skipto 13 ip from any to any in recv table(8)

3   821402  247261846 allow ip from table(2) to any

40  0 allow ip from table(3) to me dst-port 2121

50  0 allow ip from table(4) to me dst-port 161

60  0 allow ip from me to table(4) dst-port 162

70  0 allow ip from me to table(5) dst-port 514

8208657823308 allow ip from table(6) to any dst-port 179

9  6331564  753767359 allow { gre or ipencap } from table(6) to any

00010 3270 294972 allow icmp from table(7) to any

000114617 allow icmp from any to me icmptypes 3

00012 5075 323759 deny ip from any to me

000131656214  123067475 divert tablearg tcp from any to any in recv
table(8)

655340  0 fwd tablearg ip from table(12) to any

65535 11389470 1158795869 allow ip from any to any

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.

Best regards
Andreas


 --
 WBR, Andrey V. Elsukov

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

Re: ipfw / routing issue on 9.2-RELEASE

[Andrey V. Elsukov]

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 how it can affect routing.
Make sure:
1. net.inet.ip.forwarding=1 (gateway_enable=YES in rc.conf)
2. you have route and gateway is reachable (route get/arp -n).

-- 
WBR, Andrey V. Elsukov
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

Re: ipfw / routing issue on 9.2-RELEASE

[Ian Smith]

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 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 intact. Why does the kernel not forward those
packets?
  
   What is the last rule? I suspect it is deny all?
  
  
  No, last rule is allow any from any set via loader tunable
  net.inet.ip.fw.default_to_accept=1
  
  For clarity :
  
  10  0 skipto 65534 log all from table(1) to any in recv
  table(8)
  
  2  6331546  601809038 skipto 13 ip from any to any in recv table(8)
  
  3   821402  247261846 allow ip from table(2) to any
  
  40  0 allow ip from table(3) to me dst-port 2121
  
  50  0 allow ip from table(4) to me dst-port 161
  
  60  0 allow ip from me to table(4) dst-port 162
  
  70  0 allow ip from me to table(5) dst-port 514
  
  8208657823308 allow ip from table(6) to any dst-port 179
  
  9  6331564  753767359 allow { gre or ipencap } from table(6) to any
  
  00010 3270 294972 allow icmp from table(7) to any
  
  000114617 allow icmp from any to me icmptypes 3
  
  00012 5075 323759 deny ip from any to me
  
  000131656214  123067475 divert tablearg tcp from any to any in recv
  table(8)
  
  655340  0 fwd tablearg ip from table(12) to any
  
  65535 11389470 1158795869 allow ip from any to any
  
  With the above ruleset a packet
  1) triggering the first rule ( ie skipto no-op and the allow from any to
  any ) is lost.

The count on rule 1 is zero, so no packets matched it, not were 'lost'?

  2) triggering the second rule (ie skipto divert rule which returns it to
  the stack ) is forwarded.
  
  Best regards
  Andreas
  
  
   --
   WBR, Andrey V. Elsukov

If at some other times rule 1 IS matched, I suggest some renumbering so 
you can put 'count log' rules both before and after the 'fwd tablearg' 
rule; then if they 'disappear' you can see exactly where.

cheers, Ian
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

ipfw / routing issue on 9.2-RELEASE

[Andreas Nilsson]

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 add 65534 fwd tablearg all from table(12) to any

Table 1 contains prefixes that should skip the normal rules and just pass
through the box.

Table 8 contains interface names.

Table 12 is empty (so far).

What happens is that packets that trigger the first rule never get to their
destination. After looking at /var/log/security is see that packets trigger
the rule, never to be seen again. There is a route (ie not default) for
the destination, but a tcpdump on the corresponding interface shows nothing.


On changing the ruleset to
$cmd=ipfw -fq 

$cmd add 1 skipto 65533 log all from table(1) to any in recv table(8)

...

$cmd add 65533 fwd x.y.z.w ip from table(1) to any in recv table(8)

$cmd add 65534 fwd tablearg all from table(12) to any

packets get to where they should.


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 intact. Why does the kernel not forward those
packets?


Best regards

Andreas Nilsson
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

tun setup (routing?) issue in head

[Andriy Gapon]

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.255 mtu 1412 
up
ifconfig: ioctl (SIOCAIFADDR): File exists

Where tun0 is an interface created by vpnc.
ktrace gives this:
ifconfig CALL  socket(PF_INET,SOCK_DGRAM,IPPROTO_IP)
ifconfig RET   socket 3
ifconfig CALL  ioctl(0x3,SIOCSIFMTU,0x525a60)
ifconfig RET   ioctl 0
ifconfig CALL  ioctl(0x3,SIOCGIFFLAGS,0x7fffda30)
ifconfig RET   ioctl 0
ifconfig CALL  ioctl(0x3,SIOCSIFFLAGS,0x7fffda30)
ifconfig RET   ioctl 0
ifconfig CALL  ioctl(0x3,SIOCDIFADDR,0x525380)
ifconfig RET   ioctl -1 errno 49 Can't assign requested address
ifconfig CALL  ioctl(0x3,SIOCAIFADDR,0x525340)
ifconfig RET   ioctl -1 errno 17 File exists
ifconfig CALL  write(0x2,0x7fffd2d0,0xa)

So, what's happening?
Do you I have to update the ifconfig command?
Or is there some issue in the networking code?

BTW, I also get the following messages in the system log when vpnc is started:
kernel: tun0: link state changed to UP
kernel: ifa_add_loopback_route: insertion failed
I have net.link.tap.up_on_open=1 in sysctl.conf if that matters.

-- 
Andriy Gapon
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

Re: tun setup (routing?) issue in head

[Andriy Gapon]

on 25/01/2010 17:52 Li, Qing said the following:
 Yes, the failure is due to route installation. To make a long story short, 
 many of the
 scripts that worked before not necessary because of the right reasons. 
  
 I have been very busy at work, but I do have a patch and I will try to get it 
 finalized shortly.

I see, cool!
Perhaps there is some interim work-around for this issue?
I can not access my work VPN because of this and I don't like having to roll 
back
my kernel.

 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 
 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.255 mtu 
 1412 up
 ifconfig: ioctl (SIOCAIFADDR): File exists
 
 Where tun0 is an interface created by vpnc.
 ktrace gives this:
 ifconfig CALL  socket(PF_INET,SOCK_DGRAM,IPPROTO_IP)
 ifconfig RET   socket 3
 ifconfig CALL  ioctl(0x3,SIOCSIFMTU,0x525a60)
 ifconfig RET   ioctl 0
 ifconfig CALL  ioctl(0x3,SIOCGIFFLAGS,0x7fffda30)
 ifconfig RET   ioctl 0
 ifconfig CALL  ioctl(0x3,SIOCSIFFLAGS,0x7fffda30)
 ifconfig RET   ioctl 0
 ifconfig CALL  ioctl(0x3,SIOCDIFADDR,0x525380)
 ifconfig RET   ioctl -1 errno 49 Can't assign requested address
 ifconfig CALL  ioctl(0x3,SIOCAIFADDR,0x525340)
 ifconfig RET   ioctl -1 errno 17 File exists
 ifconfig CALL  write(0x2,0x7fffd2d0,0xa)
 
 So, what's happening?
 Do you I have to update the ifconfig command?
 Or is there some issue in the networking code?
 
 BTW, I also get the following messages in the system log when vpnc is started:
 kernel: tun0: link state changed to UP
 kernel: ifa_add_loopback_route: insertion failed
 I have net.link.tap.up_on_open=1 in sysctl.conf if that matters.
 
 --
 Andriy Gapon
 ___
 freebsd-curr...@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
 
 


-- 
Andriy Gapon
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

Strange Routing issue

[Hendry]

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 prefix)
   1 Neighbor, route about 6-8 Mbps traffic.

  here's the issue:
--
from quagga BGPD
--
BGPD-gw-int-2 sh ip bgp 216.136.204.117
BGP routing table entry for 216.136.204.0/24
Paths: (1 available, best #1, table Default-IP-Routing-Table)
  Advertised to non peer-group peers:
  202.69.98.3
  18059 7473 10310 26085, (aggregated by 26085 66.163.160.248)
202.43.160.77 from 202.78.192.161 (64.110.188.178)
  Origin IGP, localpref 100, valid, external, best
  Last update: Tue Aug  2 05:18:56 2005

--
from zebra daemon
--
ZEBRA-gw-int-2# sh ip route 216.136.204.117
Routing entry for 216.136.204.0/24
  Known via bgp, distance 20, metric 0, best
  Last update 00:58:07 ago
  * 202.43.160.77, via fxp0

--
From the command line
--
ro-gw-int-2# route -n get 216.136.204.117
route: writing to routing socket: No such process

--
results from another terminal while run above command,
--

ro-gw-int-2# route -nv monitor
got message of size 164 on Tue Aug  2 06:12:58 2005
RTM_GET: Report Metrics: len 164, pid: 68487, seq 1, errno 3, 
flags:UP,GATEWAY, HOST,STATIC
locks:  inits:
sockaddrs: DST,IFP
 216.136.204.117

 ro-gw-int-2# netstat -nrfinet | grep 216.136.204 (null result)

 --
 unmatched result
 --
 
BGPD-gw-int-2#sh ip bgp sum
BGP router identifier 202.69.96.214, local AS number 9785
27551 BGP AS-PATH entries
0 BGP community entries

NeighborVAS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
202.78.192.161  4   215377  61070   0  0   04d05h38m   165166

ro-gw-int-2#netstat -nrfinet | wc -l
  148886

ro-gw-int-2#netstat -m
899/1424/131072 mbufs in use (current/peak/max):
899 mbufs allocated to data
896/1024/32768 mbuf clusters in use (current/peak/max)
2404 Kbytes allocated to network (2% of mb_map in use)
0 requests for memory denied
0 requests for memory delayed
0 calls to protocol drain routines
  

is there any suggestion? we're just having a plan to increased the
the amount of memory tomorrow night from 512Mb to 1G.
but for sure this router have been quite stable for about half year
without any problem. not sure though whether its quagga or freebsd
issue.



--
cheers
hendry

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]