Netgate SG-1000 microFirewall

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Heimire

Pages: [1] 2 3 4 5 ... 8
1
General Questions / Re: allow user to choose gateway 'on the fly'
« on: January 16, 2018, 12:35:11 pm »
"The problem is that with destination ip based rules I'm unable to choose which gateway should be used to connect to any specific site unless I login to pfSense and manually change the firewall rule for that destination ip."

Based on that line I assumed he had a firewall rule that was destination spesific.
If thats the case he should be able to assign a different gateway other than the default one in the advanced settings for the rule.

So that should work I think unless he wants to use for that rule different gateway based on what he needs at that one moment but why have a destination based rule?


2
General Questions / Re: allow user to choose gateway 'on the fly'
« on: January 16, 2018, 10:58:39 am »
So if you go to the rule and expand advanced options under Extra options settings at the bottom.
you find a gateway option there.

You can't use that to select the gateway to use?

Maybe I  not understanding the issue?

3
General Questions / Added limiter resulted in spontaneous reboots
« on: January 16, 2018, 10:51:24 am »
pfsense 2.4.2 in HA mode.

Steps taken to create this mess.
On primary.
Added traffic limiter by:
Firewall/traffic shaper
Limiters
Added new
Name: l3df
bandwidth 15mb
mask: source address
Rest default

Then added to a rule
Firewall/rules
OpenVPN
edit rule
Selected the limiter for In pipe.

Hit save.

It made the primary firewall reboot.
Come up for about 15 seconds then reboot.
This continued none stop.

It replicated the settings to the backup firewall.
The backup firewall did the same thing but it crashed the file system and never came back up at all.

I managed to get into the firewall and disable the limiter and that fixed the primary. (took over an hour).
On the backup firewall I had to fix the file system and then it came backup.

Its pretty scary that a simple mistake like this will shut down both your primary and secondary.

It would be nice to have a delay in replicating firewall rules that can kill your primary. 

I assume there are no way to delay firewall rules/settings replication to prevent situations like this.



4
Just did it and noticed I got a 29ms response time on one of the pings.
First time I see that. 

Ran it again and this time I see a 234ms ping. 

...

--- 64.9.133.17 ping statistics ---
10 packets transmitted, 10 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.188/23.642/234.569/70.309 ms

Well, that would certainly explain things. This could arise from a few things, but the most likely guess is the target device handles ICMP as a very low priority. You can confirm this by using a monitor address that is a little further out into the world.

As a general rule you want to use a monitor address that is physically on the other side of your WAN link. Some people use public addresses such as Google's DNS servers. For my monitoring, I use one of my ISPs regional concentrators.

You can use the mtr package to help you choose a suitable target. Run mtr with a target of 8.8.8.8 and look at the hops along the way.

I think you hit it on the head.
This is still being setup and we have no live traffic there yet.
We are moving in there and just seen weird things we did not expect.

I will find some points to monitor outside the data center.

Thank you so much for your input.
Very helpful and I also realize I jumped to conclusion.
Should have done more than 3 ping when tested but they came back perfect every time.
I think when i did the testing earlier when i set the ping to 10 and ran it several times, I saw high numbers in probably 60-70% of the time.
Should have dug a bit deeper before posting.

H.

5
root    26113    0.0  0.0  13084  2784  -  S    16:05       0:00.00 sh -c ps -axuwww | grep dpinger 2>&1
root    26667    0.0  0.0  14728  2436  -  S    16:05       0:00.00 grep dpinger
root    28745    0.0  0.0  10980  2436  -  Is   Fri10       0:07.45 /usr/local/bin/dpinger -S -r 0 -i WAN2GW -B 64.9.133.27 -p /var/run/dpinger_WAN2GW~64.9.133.27~64.9.133.25.pid -u /var/run/dpinger_WAN2GW~64.9.133.27~64.9.133.25.sock -C /etc/rc.gateway_alarm -d 0 -s 500 -l 2000 -t 60000 -A 1000 -D 500 -L 20 64.9.133.25
root    29321    0.0  0.0  10980  2436  -  Is   Fri10       0:07.59 /usr/local/bin/dpinger -S -r 0 -i WANGW -B 64.9.133.19 -p /var/run/dpinger_WANGW~64.9.133.19~64.9.133.17.pid -u /var/run/dpinger_WANGW~64.9.133.19~64.9.133.17.sock -C /etc/rc.gateway_alarm -d 0 -s 500 -l 2000 -t 60000 -A 1000 -D 500 -L 20 64.9.133.17
Execute Shell Command

ps -axuwww | grep dpinger


The ping was done from the diagnostics/ping menu option.
I entered the gateway 64.9.133.17
Selected WAN for the source address.
then ran the ping.

Just did it and noticed I got a 29ms response time on one of the pings.
First time I see that. 

Ran it again and this time I see a 234ms ping. 


PING 64.9.133.17 (64.9.133.17) from 64.9.133.19: 56 data bytes
64 bytes from 64.9.133.17: icmp_seq=0 ttl=255 time=0.278 ms
64 bytes from 64.9.133.17: icmp_seq=1 ttl=255 time=29.385 ms
64 bytes from 64.9.133.17: icmp_seq=2 ttl=255 time=0.207 ms
64 bytes from 64.9.133.17: icmp_seq=3 ttl=255 time=0.239 ms
64 bytes from 64.9.133.17: icmp_seq=4 ttl=255 time=0.216 ms
64 bytes from 64.9.133.17: icmp_seq=5 ttl=255 time=0.196 ms
64 bytes from 64.9.133.17: icmp_seq=6 ttl=255 time=0.253 ms
64 bytes from 64.9.133.17: icmp_seq=7 ttl=255 time=0.202 ms
64 bytes from 64.9.133.17: icmp_seq=8 ttl=255 time=0.188 ms
64 bytes from 64.9.133.17: icmp_seq=9 ttl=255 time=0.198 ms

--- 64.9.133.17 ping statistics ---
10 packets transmitted, 10 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.188/3.136/29.385/8.750 ms


Results
PING 64.9.133.17 (64.9.133.17) from 64.9.133.19: 56 data bytes
64 bytes from 64.9.133.17: icmp_seq=0 ttl=255 time=0.253 ms
64 bytes from 64.9.133.17: icmp_seq=1 ttl=255 time=0.191 ms
64 bytes from 64.9.133.17: icmp_seq=2 ttl=255 time=0.198 ms
64 bytes from 64.9.133.17: icmp_seq=3 ttl=255 time=0.194 ms
64 bytes from 64.9.133.17: icmp_seq=4 ttl=255 time=234.569 ms
64 bytes from 64.9.133.17: icmp_seq=5 ttl=255 time=0.210 ms
64 bytes from 64.9.133.17: icmp_seq=6 ttl=255 time=0.190 ms
64 bytes from 64.9.133.17: icmp_seq=7 ttl=255 time=0.195 ms
64 bytes from 64.9.133.17: icmp_seq=8 ttl=255 time=0.188 ms
64 bytes from 64.9.133.17: icmp_seq=9 ttl=255 time=0.235 ms

--- 64.9.133.17 ping statistics ---
10 packets transmitted, 10 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.188/23.642/234.569/70.309 ms

6
The dashboard shows RTT to between 2 and 12ms and RTTsd can be over 20ms.
But if I ping the gateway from the firewall its less than 1ms.  Same from backup firewall.

Is it possible that you have a monitor address set that is different than the gateway address?

Yes, but it still shows the same numbers.
Changed monitor address to one hop up.

I really need to figure this out, its driving me nuts.

7
Packages / Re: FRR BGP Config example request.
« on: January 04, 2018, 12:40:27 pm »
I see what you mean about the diagram.
I guess thats another thing I am not good at :)

Will take a stab at what you wrote.

Thank you so much for taking the time.

H.

8
I have no idea why this is taking place and its really bugging me.

pfSense 2.4.2_P1 in HA setup.
In a data center so our gateways are in the same room pretty much.
Its a 1gb LAN connection.

The dashboard shows RTT to between 2 and 12ms and RTTsd can be over 20ms.
But if I ping the gateway from the firewall its less than 1ms.  Same from backup firewall.

If I ping from a server on the LAN side to the same gateway I am seeing sub ms too.
So pinging appears to be normal but dashboard is showing different numbers.

The data center is using VSF I am sure since the gateways can't be pinged if we are not connected.

I took a simple pfsense box and plugged it in to the same port as the primary and it shows the same high RTT/RTTsd.
Loaded 2.3.5 on the box but nothing changed, I was thinking it could be a bug, or something.

Moved that same firewall to another connection in the same data center (onsite tech workstation area) and it shows normal sub ms RTT and normal RTTsd.

Any idea why this is taking place. 
No idea why this is bugging me so much but I might need mental help to get over this :)

H.


9
Packages / Re: FRR BGP Config example request.
« on: January 04, 2018, 08:56:27 am »
No.

WAN1 and WAN2 is active on both firewalls with CARP VIPs.

We run 2.26 in this setup (designed by pfsense by the way) and it works fine.

In the new data center we are running 2.4.2_P1 but using FRR instead of OpenBGP.
In this data center we are seeing a long fail over so I think its due to my lack of understanding of the FRR package.
So thats why I am asking for some assistance.

I think I need to prepend the backup WAN connection WAN2 with prepend-self 2 but not exactly sure what the best way to do that in FRR.
I just did a manual config in 2.26 with openBGP.

I also probably need a deny from all and allow from the 2 gateways.

Right now this works, the fail over CARP works.
Only problem is it takes a long time to fail over the BGP.
Its like the primary shuts down the BGP session so all connectivity is lost until the BGP session has been established on the secondary.
Takes up to a few minutes to see connectivity.

I am sure its lack of understand on my part when it comes to things like hold time, neighbor config,etc.

Thank you for taking the time to respond.

H.

10
Packages / FRR BGP Config example request.
« on: January 03, 2018, 05:27:54 pm »
Hey,

I am trying to make FRR BGP work for us.
It works but I think we are seeing a long fail over time.

If I reboot the primary it can take 2 minutes before we get connectivity again.

Or if I disable CARP on primary the connection goes down for 8 seconds then comes backup for some seconds, goes back down for 9 seconds then comes up again.
The seconds vary.


We are in a data center with 2 connections to the cabinet.
A /29 for each firewall. 
FRR is running on both.

I am not sure if I can do anything about speeding up the fail over.

I feel like I am missing the obvious but not sure where to look.
Any suggestions?


BGP configuration primary.
##################### DO NOT EDIT THIS FILE! ######################
###################################################################
# This file was created by an automatic configuration generator.  #
# The contents of this file will be overwritten without warning!  #
###################################################################
password Super.1346
log syslog

# BGP Config
router bgp 18599
  bgp log-neighbor-changes
  bgp router-id 64.9.133.18
  timers bgp 6 20
  address-family ipv4 unicast
   network 168.245.135.0/24
  exit-address-family

  # BGP Neighbors
  neighbor 64.9.133.17 remote-as 3900
  neighbor 64.9.133.17 description Primary Datafoundry
  address-family ipv4 unicast
    neighbor 64.9.133.17 activate
    no neighbor 64.9.133.17 send-community
    neighbor 64.9.133.17 next-hop-self
    neighbor 64.9.133.17 soft-reconfiguration inbound
  exit-address-family
  neighbor 64.9.133.25 remote-as 3900
  neighbor 64.9.133.25 description Backup Datafoundry
  address-family ipv4 unicast
    neighbor 64.9.133.25 activate
    no neighbor 64.9.133.25 send-community
    neighbor 64.9.133.25 next-hop-self
    neighbor 64.9.133.25 soft-reconfiguration inbound
  exit-address-family

11
General Questions / duplicate echo reply received
« on: December 23, 2017, 09:37:32 am »
We are seeing this on both firewalls. 
They are located in a data center so the gateway is just a hop a way on a gig connection.

We have 2 different circuits using BGP and CARP.


Time   Process   PID   Message
Dec 23 08:09:33   dpinger      WANGW 64.9.133.17: duplicate echo reply received
Dec 23 07:57:35   dpinger      WAN2GW 64.9.133.25: duplicate echo reply received
Dec 23 07:03:20   dpinger      WANGW 64.9.133.17: duplicate echo reply received
Dec 23 06:36:04   dpinger      WANGW 64.9.133.17: duplicate echo reply received
Dec 23 06:35:40   dpinger      WANGW 64.9.133.17: duplicate echo reply received
Dec 23 05:37:53   dpinger      WAN2GW 64.9.133.25: duplicate echo reply received
Dec 23 03:30:37   dpinger      WAN2GW 64.9.133.25: duplicate echo reply received
Dec 23 03:14:43   dpinger      WAN2GW 64.9.133.25: duplicate echo reply received
Dec 23 02:07:58   dpinger      WANGW 64.9.133.17: duplicate echo reply received
Dec 23 00:39:56   dpinger      WAN2GW 64.9.133.25: duplicate echo reply received
Dec 22 22:40:07   dpinger      WANGW 64.9.133.17: duplicate echo reply received
Dec 22 22:27:43   dpinger      WAN2GW 64.9.133.25: duplicate echo reply received

12
Routing and Multi WAN / Re: FRR configuration
« on: December 22, 2017, 06:34:03 pm »
Hey there,

I am a gold member and will follow that one.
Those hangouts are really good, I recommend everybody to get a membership.
The hangouts and autobackup is worth it for sure.

I have been trying to get this to work but im really confused.
Its so much more info there and not sure how it all ties together yet.
I got the openbgp to work so I just need to understand the difference between the two in whats required.

Thanks.

13
Routing and Multi WAN / FRR configuration
« on: December 22, 2017, 10:46:23 am »
Does anyone have a simple quide on how to configure FRR to work with BGP?


14
Routing and Multi WAN / Re: 2.4.2 BGP working correctly?
« on: December 22, 2017, 10:45:38 am »
Its confirmed its not working correctly.

Recommendation is to use FRR instead of OpengBGP package.

Now how to configure FRR?
Its a bit intimidating...


15
Routing and Multi WAN / 2.4.2 BGP working correctly?
« on: December 18, 2017, 04:19:04 pm »
We have a HA setup in one data center running 2.26.
We are using BGP with no problems.

In the new data center we are running another HA setup running 2.4.2.

We have 2 connections, we are using CARP and BGP.

The weird thing we are dealing with is that when we tell the primary firewall to disable CARP BOTH firewalls are closing the session so it takes a very long time to fail over.

This is what the provider sent me.
Dec 18 10:50:46 CST: %BGP-SW2-5-NBR_RESET: Neighbor 64.9.133.26 reset (Peer closed the session) Dec 18 10:50:46 CST: %BGP-SW2-5-NBR_RESET: Neighbor 64.9.133.18 reset (Peer closed the session) Dec 18 10:50:46 CST: %BGP-SW2-3-NOTIFICATION: received from neighbor
64.9.133.26 6/2 (Administrative Shutdown) 0 bytes Dec 18 10:50:46 CST: %BGP-SW2-3-NOTIFICATION: received from neighbor
64.9.133.18 6/2 (Administrative Shutdown) 0 bytes Dec 18 10:50:46 CST: %BGP-SW2-5-ADJCHANGE: neighbor 64.9.133.18 Down Peer closed the session Dec 18 10:50:46 CST: %BGP_SESSION-SW2-5-ADJCHANGE: neighbor
64.9.133.18 IPv4 Unicast topology base removed from session  Peer closed the session Dec 18 10:50:46 CST: %BGP-SW2-5-ADJCHANGE: neighbor 64.9.133.26 Down Peer closed the session Dec 18 10:50:46 CST: %BGP_SESSION-SW2-5-ADJCHANGE: neighbor
64.9.133.26 IPv4 Unicast topology base removed from session  Peer closed the session


Is it possible this is a bug or do I have something screwed up.  This is also the same setup where we see 2-8ms on the dashboard gateway screens but when you ping the gateways from the firewall or laptop its sub 1ms.

Our BGP config.
# This file was created by the package manager. Do not edit!

AS 18599
fib-update yes
holdtime 20
listen on 0.0.0.0
network 168.245.135.0/24
neighbor 64.9.133.17 {
descr "WAN1 BGP"
remote-as 3900
local-address 64.9.133.18
set nexthop self
}
neighbor 64.9.133.25 {
descr "WAN2 BGP"
remote-as 3900
local-address 64.9.133.26
set nexthop self
set prepend-self 2
}
deny from any
deny to any
allow from 64.9.133.17
allow to 64.9.133.17
allow from 64.9.133.25
allow to 64.9.133.25



Pages: [1] 2 3 4 5 ... 8