Re: Issue with pf route-to and routing tables

for the world facing side of my network. I have a wireguard > network to link it up to a home router and other devices. My wireguard > traffic is coming onto my VM through wg0. > > On my home router, I'm redirecting all wifi traffic to wg0 using the > routing tables like so:

Issue with pf route-to and routing tables

link it up to a home router and other devices. My wireguard traffic is coming onto my VM through wg0. On my home router, I'm redirecting all wifi traffic to wg0 using the routing tables like so: default192.168.0.1 wg0 IP_VM IP_Gatewaybse0 192.168.0.

Re: Kerberos SSH routing tables problem

to use Kerberised SSH to perform some work on one of .mil servers. I opened egress ports kerberos, klogin, kshell TCP protocol as well as kerberos UDP. After the work is finished and desktops are "logged out" routing tables (dns) are in a bad state on the firewall. A simple pfctl -F a

Re: Kerberos SSH routing tables problem

NERIC.MP#0 octeon > > > > The desktops behind the firewall have to use Kerberised SSH to perform > > some work on one of .mil servers. I opened egress ports kerberos, > > klogin, kshell TCP protocol as well as kerberos UDP. After the work is > > finished and desktops a

Re: Kerberos SSH routing tables problem

SSH to perform > some work on one of .mil servers. I opened egress ports kerberos, > klogin, kshell TCP protocol as well as kerberos UDP. After the work is > finished and desktops are "logged out" routing tables (dns) are in a bad > state on the firewall. A simple >

Re: Kerberos SSH routing tables problem

GENERIC.MP#0 octeon The desktops behind the firewall have to use Kerberised SSH to perform some work on one of .mil servers. I opened egress ports kerberos, klogin, kshell TCP protocol as well as kerberos UDP. After the work is finished and desktops are "logged out" routing tables (dns) ar

Kerberos SSH routing tables problem

, klogin, kshell TCP protocol as well as kerberos UDP. After the work is finished and desktops are "logged out" routing tables (dns) are in a bad state on the firewall. A simple pfctl -F all -f /etc/pf.conf fixes the problem and desktops can again do DNS resolving and surfing the Interne

Re: Bridged vether interfaces can't talk to each other (multiple routing tables)

ddress[1]. I have it mostly working, but my interfaces can't > talk to each other. > > All traffic should use the primary IP, and most services should listen > on that. The secondary IP should only be used on-demand for one or two > services. > > Thinking that separate routing table

Re: Bridged vether interfaces can't talk to each other (multiple routing tables)

On 22 April 2017 at 04:22, Edgar Pettijohn wrote: > On 04/21/17 20:49, Anders Andersson wrote: >> >> Now to my problem: I have no connection between vether0<->vether1. >> >> # traceroute -nvq1 10.0.0.3 >> traceroute to 10.0.0.3 (10.0.0.3), 64 hops max, 40

Re: Bridged vether interfaces can't talk to each other (multiple routing tables)

. All traffic should use the primary IP, and most services should listen on that. The secondary IP should only be used on-demand for one or two services. Thinking that separate routing tables can solve this, I have configured my network like this[2][3]: # cat hostname.em2 up # cat

Bridged vether interfaces can't talk to each other (multiple routing tables)

, and most services should listen on that. The secondary IP should only be used on-demand for one or two services. Thinking that separate routing tables can solve this, I have configured my network like this[2][3]: # cat hostname.em2 up # cat hostname.vether0 lladdr 00:00:00:00:00:02

Re: Change routing tables when ISP goes down

Thanks to everyone for your help/suggestions. I think that I'm headed in the right direction. I still can't seem to force a ping through a particular interface, even when I have both interfaces as default routes (I've tried both with and without mpath). If it matters, in both cases I used a

Re: Change routing tables when ISP goes down

On 02-10-2014 10:11, Jeff wrote: I still can't seem to force a ping through a particular interface, even when I have both interfaces as default routes (I've tried both with and without mpath). If it matters, in both cases I used a lower priority (higher #) for our low speed metered connection.

Re: Change routing tables when ISP goes down

Hello Jeff, Wednesday, October 1, 2014, 12:14:53 PM, you wrote: J It sounds like ping -I is what I was looking for, but when I use it, it seems J to be sending out the packet with the right source address, but sending it to J the wrong interface.are there any tricks here? J Here's some

Re: Change routing tables when ISP goes down

grazzol...@gmail.com (Giancarlo Razzolini), 2014.10.02 (Thu) 15:39 (CEST): On 02-10-2014 10:11, Jeff wrote: I still can't seem to force a ping through a particular interface, even when I have both interfaces as default routes (I've tried both with and without mpath). If it matters, in

Re: Change routing tables when ISP goes down

On 2014-10-02, Jeff j...@usedmoviefinder.com wrote: Thanks to everyone for your help/suggestions. I think that I'm headed in the right direction. I still can't seem to force a ping through a particular interface, even when I have both interfaces as default routes (I've tried both with and

Re: Change routing tables when ISP goes down

On 2014/10/02 17:21, aluc...@phangos.fr wrote: Or you can use a static route to force reaching the ip from an interface. Would be more secure than bringing down a working interface just to check if another one is working ... I didn't suggest that ;) This would only be needed to spot the main

Re: Change routing tables when ISP goes down

Hi Everyone, With the addition of a carefully constructed route-to rule I now have all of the individual pieces working. Now, with some careful plumbing and testing I should be all set. The final solution will be a combination of ifstated, multipath routing (prioritized) and ping -I; thanks to

Re: Change routing tables when ISP goes down

On 02-10-2014 16:12, Jeff wrote: With the addition of a carefully constructed route-to rule I now have all of the individual pieces working. Now, with some careful plumbing and testing I should be all set. The final solution will be a combination of ifstated, multipath routing (prioritized)

Re: Change routing tables when ISP goes down

Or you can use a static route to force reaching the ip from an interface. Would be more secure than bringing down a working interface just to check if another one is working ... Cheers, Louis On 2014-10-02 17:09, Stuart Henderson wrote: On 2014-10-02, Jeff j...@usedmoviefinder.com wrote:

Change routing tables when ISP goes down

I have a very unreliable ISP (approximately 97% uptime). Many of the times that they go down, I'm connected and can ping within their limited network, but can't get to the outside world. In these cases, I have an alternate slow speed connection that I use. Right now, I manually change the

Re: Change routing tables when ISP goes down

ifstated could do it ...

Re: Change routing tables when ISP goes down

On Wed, Oct 01, 2014 at 11:10:12AM -0400, Jeff wrote: I have a very unreliable ISP (approximately 97% uptime). Many of the times that they go down, I'm connected and can ping within their limited network, but can't get to the outside world. In these cases, I have an alternate slow speed

Re: Change routing tables when ISP goes down

On 2014-10-01 16:10, Jeff wrote: I have a very unreliable ISP (approximately 97% uptime). Many of the times that they go down, I'm connected and can ping within their limited network, but can't get to the outside world. In these cases, I have an alternate slow speed connection that I use.

Re: Change routing tables when ISP goes down

10 - 4 fpx1 -- View this message in context: http://openbsd.7691.n7.nabble.com/Change-routing-tables-when-ISP-goes-down-tp256610p256624.html Sent from the openbsd user - misc mailing list archive at Nabble.com.

Re: Change routing tables when ISP goes down

On Wed, Oct 1, 2014 at 8:10 AM, Jeff j...@usedmoviefinder.com wrote: I have a very unreliable ISP (approximately 97% uptime). Many of the times that they go down, I'm connected and can ping within their limited network, but can't get to the outside world. In these cases, I have an

Re: Change routing tables when ISP goes down

It sounds like ping -I is what I was looking for, but when I use it, it seems to be sending out the packet with the right source address, but sending it to the wrong interface.are there any tricks here? Here's some data (edited) to show what I'm seeing: fxp0: inet 10.16.100.1 netmask

Re: Change routing tables when ISP goes down

On Wed, Oct 1, 2014 at 2:10 PM, Gerald Chudyk gchu...@gmail.com wrote: I have been casually working on this for some time now. Hey, nice work! -- Don't eat anything you've ever seen advertised on TV - Michael Pollan, author of In Defense of Food

Re: Change routing tables when ISP goes down

On 01-10-2014 14:14, Jeff wrote: It sounds like ping -I is what I was looking for, but when I use it, it seems to be sending out the packet with the right source address, but sending it to the wrong interface.are there any tricks here? You must enforce through pf route-to the packets to go

Re: Routing tables and pf rules with using 2 DHCP WAN interfaces ...

Hi Le 06/08/2014 15:15, Stuart Henderson a écrit : On 2014-08-04, Christophe t...@stuxnet.org wrote: Second question : I used to write route-to and reply-to rules in pf.conf in a static context. As far as I've seen, there are modifiers on interface specifications like :network or :peer. But

Re: Routing tables and pf rules with using 2 DHCP WAN interfaces ...

On 2014-08-04, Christophe t...@stuxnet.org wrote: Second question : I used to write route-to and reply-to rules in pf.conf in a static context. As far as I've seen, there are modifiers on interface specifications like :network or :peer. But is there a :gateway or something similar telling pf

Routing tables and pf rules with using 2 DHCP WAN interfaces ...

Hi misc@, I was wondering about the behavior of OpenBSD in this case (not a production case at this time). 2 WAN interfaces (Ethernet / IPv4 DHCP) , linked to an OpenBSD box and 1 LAN interface (Ethernet / IPv4 static address) WAN1 (em0 DHCP) - |--- OpenBSD - LAN

Re: Routing tables and pf rules with using 2 DHCP WAN interfaces ...

On Mon, Aug 04, 2014 at 08:39:10PM +0200, Christophe wrote: Hi misc@, I was wondering about the behavior of OpenBSD in this case (not a production case at this time). 2 WAN interfaces (Ethernet / IPv4 DHCP) , linked to an OpenBSD box and 1 LAN interface (Ethernet / IPv4 static address)

Re: Routing tables and pf rules with using 2 DHCP WAN interfaces ...

On 04-08-2014 15:39, Christophe wrote: I was wondering about the behavior of OpenBSD in this case (not a production case at this time). 2 WAN interfaces (Ethernet / IPv4 DHCP) , linked to an OpenBSD box and 1 LAN interface (Ethernet / IPv4 static address) WAN1 (em0 DHCP) -

Re: Routing tables and pf rules with using 2 DHCP WAN interfaces ...

On Aug 4, 2014, at 1:39 PM, Christophe t...@stuxnet.org wrote: Hi misc@, I was wondering about the behavior of OpenBSD in this case (not a production case at this time). 2 WAN interfaces (Ethernet / IPv4 DHCP) , linked to an OpenBSD box and 1 LAN interface (Ethernet / IPv4 static

Re: Routing tables and pf rules with using 2 DHCP WAN interfaces ...

On Mon, Aug 04, 2014 at 08:39:10PM +0200, Christophe wrote: Hi misc@, I was wondering about the behavior of OpenBSD in this case (not a production case at this time). 2 WAN interfaces (Ethernet / IPv4 DHCP) , linked to an OpenBSD box and 1 LAN interface (Ethernet / IPv4 static address)

Re: Routing tables and pf rules with using 2 DHCP WAN interfaces ...

On 04-08-2014 17:01, Fabian Raetz wrote: Maybe giving one of your interfaces a lower priority could solve this problem in a simple setup? If used with mpath routing, then probably this would work. As I mentioned, there is only need to take proper care of the resolv.conf file, since both

Re: OpenBGPD: high CPU with huge routing tables

On Wed, Aug 31, 2011 at 02:17:57PM -0500, kevin brintnall wrote: Hi, I've looked for a mailing list for OpenBGPD but come up empty. If there's a better place to report this, please let me know. No this is fine. I'm using OpenBGPD as a fairly large route collector. In total, about 75

Re: OpenBGPD: high CPU with huge routing tables

On Fri, Sep 16, 2011 at 07:50:21AM -0500, Claudio Jeker wrote: I find that during start-up, the CPU of the route decision engine process is steady between 90-100%. During this time, bgpctl hangs. This lasts at least 45 minutes. I believe most of the CPU is spent in path_lookup(),

OpenBGPD: high CPU with huge routing tables

Hi, I've looked for a mailing list for OpenBGPD but come up empty. If there's a better place to report this, please let me know. I'm using OpenBGPD as a fairly large route collector. In total, about 75 neighbors announcing ~21 million prefixes. This is openbgpd-4.9.20110612_1 running on

Re: FYI: fixed in -current (Was: openbgp not exporting ipv6 to routing tables)

On 5 Jun 2007, at 08:42, OndEej SurC= wrote: Henning Brauer pm9e v So 21. 04. 2007 v 15:38 +0200: * Ond??ej Sur?? [EMAIL PROTECTED] [2007-04-21 14:58]: Hi, Jon Morby pm9e v So 21. 04. 2007 v 12:13 +0100: Not sure if you're still trying to fix this, or if you're sorted but if you're

multiple routing tables pf question

I have two ISPs on two nics on my router/firewall and I use some route-to rules to make traffic nat out on a specific interface and gateway. Similar to the set-up described here: http://www.openbsd.org/faq/pf/pools.html#outgoing Instead of using route-to, can I set up a second route (eg: route

Re: multiple routing tables pf question

Also, I forgot that NAT happens before filtering. That makes what I'm trying to do here more complicated if not impossible. Maybe I should just use route-to :-)

2 ISPs, 2 dhclients, 2 routing tables?

I have an OpenBSD box at my office, it's hooked up to a cable modem and does NAT. We had a DSL modem put in yesterday that we want to use for certain users or certain ports or if the cable dies. In order to properly NAT out on the ADSL link I know I can use a pf rule with route-to but I'm

FYI: fixed in -current (Was: openbgp not exporting ipv6 to routing tables)

Henning Brauer pm9e v So 21. 04. 2007 v 15:38 +0200: * Ond??ej Sur?? [EMAIL PROTECTED] [2007-04-21 14:58]: Hi, Jon Morby pm9e v So 21. 04. 2007 v 12:13 +0100: Not sure if you're still trying to fix this, or if you're sorted but if you're still having problems What does

Re: openbgp not exporing ipv6 to routing tables

On 21 Apr 2007, at 14:38, Henning Brauer wrote: * Ond??ej Sur?? [EMAIL PROTECTED] [2007-04-21 14:58]: Hi, Jon Morby pm9e v So 21. 04. 2007 v 12:13 +0100: Not sure if you're still trying to fix this, or if you're sorted but if you're still having problems What does your filters

Re: openbgp not exporing ipv6 to routing tables

On Wed, May 02, 2007 at 11:50:33AM +0100, Jon Morby wrote: On 21 Apr 2007, at 14:38, Henning Brauer wrote: * Ond??ej Sur?? [EMAIL PROTECTED] [2007-04-21 14:58]: Hi, Jon Morby pm9e v So 21. 04. 2007 v 12:13 +0100: Not sure if you're still trying to fix this, or if you're sorted

Re: openbgp not exporing ipv6 to routing tables

with IPv6. I have tried google and irc, but without success. I am receiving IPv6 prefixes just fine (791 from upstream transit, 140 from local IX), but they are not exported to kernel routing tables.

Re: openbgp not exporing ipv6 to routing tables

Hi, Jon Morby pm9e v So 21. 04. 2007 v 12:13 +0100: Not sure if you're still trying to fix this, or if you're sorted but if you're still having problems What does your filters section look like ? It's very simple now - none. But filters just modify prefixes accepted and not coupling.

Re: openbgp not exporing ipv6 to routing tables

* Ond??ej Sur?? [EMAIL PROTECTED] [2007-04-21 14:58]: Hi, Jon Morby pm9e v So 21. 04. 2007 v 12:13 +0100: Not sure if you're still trying to fix this, or if you're sorted but if you're still having problems What does your filters section look like ? It's very simple now -

openbgp not exporing ipv6 to routing tables

Hi, I have configured openbgpd on openbsd 4.0 (upgraded from 3.8) and there seems to be problem with IPv6. I have tried google and irc, but without success. I am receiving IPv6 prefixes just fine (791 from upstream transit, 140 from local IX), but they are not exported to kernel routing tables

Re: openbgp not exporing ipv6 to routing tables

IX), but they are not exported to kernel routing tables. do the v6 nexthops show up in bgpctl sh nex ? -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application

Re: openbgp not exporing ipv6 to routing tables

prefixes just fine (791 from upstream transit, 140 from local IX), but they are not exported to kernel routing tables. do the v6 nexthops show up in bgpctl sh nex ? They do: # bgpctl sh next

routing tables

hi i read the man page fro netstat route routed ifconfig all the section 6 of the facks and i cant find where i should put the routing info now i am doing route add 198.162.15.0/8 http://198.162.15.0/8 .. route add 10.98.0.0/16 http://10.98.0.0/16 but when i reboot i must put it again.

Re: routing tables

On 11/15/05, David fire [EMAIL PROTECTED] wrote: hi i read the man page fro netstat route routed ifconfig all the section 6 of the facks and i cant find where i should put the routing info now i am doing route add 198.162.15.0/8 http://198.162.15.0/8 .. route add 10.98.0.0/16