My pfSense keeps breaking (novel inside…)
-
I can't remember ALL of the packages that I had installed the first time this happened but some of them were:
pfBlocker
file manager
squid
squidguard
and maybe one or two more (all reporting ones)This last time around I had just the following:
file manager
squid
squidguard
and I tried out the widescreen theme. -
Well none of those packages look like obvious suspects, never the less I would try without any packages to rule that out. :-\
Steve
-
I've already uninstalled all the packages.
The current state I'm in is:
No packages installed.
Reset to factory defaults.
Only the most basic settings have been applied in order to get an internet connection up on it.And yet I still see no traffic. :-\
It's as I were creating a super-massive star when all of a sudden it imploded into a supernova and warped into a blackhole. :'(
I want my super-massive pfSense star back. -
The only thing left for me to do is re-install and start from scratch… AGAIN.
But before I do that, I figured I'd post on here to see if someone had a suggestion to diagnose this shit and hopefully stop others from running into the same problem AND hopefully prevent me from running through it all over again a third time.
I figured if there truly is a horribad bug somewhere in the code, someone would want to know about it and get it fixed.
-
ok, so I turned on accessing the web configurator from the wan side. One of my internet connections is DSL which uses a wired/wireless router/modem combo. So I've plugged my laptop into one of the other wired ports on the little DSL router and can access my pfSense box through the WAN port there. So at least SOME traffic is flowing through that connection. But it's not showing up in the states/firewall logs.
Still no pings, webpages, email, etc are going through it though. :'(
Can't get a connection to the internet through the pfSense. :-\ -
The only thing left for me to do is re-install and start from scratch… AGAIN.
There are still a number of alternatives, including plugging your laptop into the DSL router and attempting to access the pfSense WAN port.
One of my internet connections is DSL
What are the others?
So I've plugged my laptop into one of the other wired ports on the little DSL router and can access my pfSense box through the WAN port there.
Can you also access the management interface on the DSL router? What does it tell you about the WAN interface of the DSL router?
What is the interface type of your pfSense WAN interface? (Static? DHCP? PPP?)
Please post the output of of the pfSense shell command```
netstat -rn -f inet; traceroute -n 8.8.8.8
-
Tried pinging with pfSense's web configurator (under Diagnostics >> Ping) to both 4.2.2.2 and google.com (along with a handful of other sites) and get no response. Tried pinging the DSL router, and get a response. Tried pinging my laptop that is also plugged into the same router and get a response form my laptop's ip address.
Still nothing shows in states/firewall logs though?
I'll try that traceroute command.
-
Here are the results:
netstat -rn -f inet ; traceroute -n 8.8.8.8
Routing tablesInternet:
Destination Gateway Flags Refs Use Netif Expire
127.0.0.1 link#12 UH 0 3412 lo0
192.168.2.0/24 link#7 U 0 10355 em2
192.168.2.2 link#7 UHS 0 0 lo0
192.168.168.0/24 link#5 U 0 341 em0
192.168.168.1 link#5 UHS 0 0 lo0
traceroute: findsaddr: failed to connect to peer for src addr selection. -
You don't have a default route hence most of the traffic that would normally go out the WAN interface doesn't go out the WAN interface because there isn't a route saying that is where it should go.
Your pfSense WAN interface type is? (Depending on that I might be able to give you a pfSense shell command to add a default route.) But that won't help if the upstream link from your DSL router is broken. Can you get status of the upstream (to the Internet) link on the DSL router?
What version of pfSense are you running? Please post the version information from the home page of your pfSense box.
-
Hmm, you have no default route and no route to anywhere outside your network. Problem!
Is your WAN connection up? (or was it when you did this).
@soteriologist:I've already uninstalled all the packages.
The reason I suspected packages is that they sometimes either overwrite things they shouldn't or remove things they shouldn't when you uninstall them.
Uninstalling all the packages is not necessarily the same thing as never having installed them! ::)
Something has messed up your routing table, either directly or by messing up something that controls the routing table.
Steve
Edit: Typed too slow.
-
I'm able to get an internet connection fine through all of my WAN devices I've had in the past (and currently have) attached to pfSense. Even when I plug in using the same cables/ports that pfSense would use to those devices.
I ruled out any hardware problems at the get-go.
As for my current version:
Version 2.0.1-RELEASE (amd64)
built on Mon Dec 12 18:16:13 EST 2011
FreeBSD 8.1-RELEASE-p6As for the default route, I can check mark that box for the interface. Right now it's unchechked because I had a loadbalancing group created and had "Allow default gateway switching" under "System >> Advanced >> Miscellaneous >> Load Balancing" checked.
I can recheck to have just that default DSL line checked as the "Default Gateway" and uncheck the other setting… brb.
-
You need to set a default gateway even if you're policy routing your egress traffic. And uncheck the default gateway switching.
What type of WANs?
-
I just rechecked to have just that default DSL line checked as the "Default Gateway" and unchecked "Allow default gateway switching" under "System >> Advanced >> Miscellaneous >> Load Balancing".
Still no ping response beyond the router/modem it's plugged into.
Stil no internet connection.
Still nothing in state/firewall logs.Re-ran traceroute and this is what I have now:
netstat -rn -f inet; traceroute -n 8.8.8.8
Routing tables
Internet:
Destination Gateway Flags Refs Use Netif Expire
default 192.168.2.2 US 0 51 em2
127.0.0.1 link#12 UH 0 3524 lo0
192.168.2.0/24 link#7 U 0 19094 em2
192.168.2.2 link#7 UHS 0 0 lo0
192.168.168.0/24 link#5 U 0 341 em0
192.168.168.1 link#5 UHS 0 0 lo0
traceroute to 8.8.8.8 (8.8.8.8), 64 hops max, 52 byte packets -
The three WANs that I have are:
One DSL connection through a Verizon router/modem
One T1 through an AdTran DSU/CSU
One T1 through a Cisco DSU/CSUAT THE MOMENT I'm ONLY using the DSL for testing. Just to simplify things and because the entire company is actively using the two T1s at office. But when I had everything plugged in during off hours, they were all working fine until… well... everything stopped working. So I had to put everything back they way I had it in the very late hours of the night before everyone came back in the next day and BACK TO THE DRAWING BOARD!
-
Re-ran traceroute and this is what I have now:
Your traceroute output is incomplete.
-
Re-ran traceroute and this is what I have now:
Your traceroute output is incomplete.
Ya… just realized that I hadn't copied everything, SORRY!
Here we go:
netstat -rn -f inet; t raceroute -n 8.8.8.8
Routing tablesInternet:
Destination Gateway Flags Refs Use Netif Expire
default 192.168.2.2 US 0 201 em2
127.0.0.1 link#12 UH 0 3568 lo0
192.168.2.0/24 link#7 U 0 22223 em2
192.168.2.2 link#7 UHS 0 0 lo0
192.168.168.0/24 link#5 U 0 341 em0
192.168.168.1 link#5 UHS 0 0 lo0
traceroute to 8.8.8.8 (8.8.8.8), 64 hops max, 52 byte packets
1 * * *
2 * *traceroute: sendto: Host is down
traceroute: wrote 8.8.8.8 52 chars, ret=-1
*
traceroute: sendto: Host is down
3 traceroute: wrote 8.8.8.8 52 chars, ret=-1
*traceroute: sendto: Host is down
traceroute: wrote 8.8.8.8 52 chars, ret=-1
*traceroute: sendto: Host is down
traceroute: wrote 8.8.8.8 52 chars, ret=-1
*
traceroute: sendto: Host is down
4 traceroute: wrote 8.8.8.8 52 chars, ret=-1
*traceroute: sendto: Host is down
traceroute: wrote 8.8.8.8 52 chars, ret=-1
*traceroute: sendto: Host is down
traceroute: wrote 8.8.8.8 52 chars, ret=-1
*
traceroute: sendto: Host is down
5 traceroute: wrote 8.8.8.8 52 chars, ret=-1
*traceroute: sendto: Host is down
traceroute: wrote 8.8.8.8 52 chars, ret=-1
*traceroute: sendto: Host is down
traceroute: wrote 8.8.8.8 52 chars, ret=-1
*
traceroute: sendto: Host is down
6 traceroute: wrote 8.8.8.8 52 chars, ret=-1
*traceroute: sendto: Host is down
traceroute: wrote 8.8.8.8 52 chars, ret=-1
*traceroute: sendto: Host is down
traceroute: wrote 8.8.8.8 52 chars, ret=-1
*
traceroute: sendto: Host is down
7 traceroute: wrote 8.8.8.8 52 chars, ret=-1
^C -
traceroute to 8.8.8.8 (8.8.8.8), 64 hops max, 52 byte packets
1 * * *
2 * *traceroute: sendto: Host is down
traceroute: wrote 8.8.8.8 52 chars, ret=-1
*
traceroute: sendto: Host is down1 looks like your DSL router doesn't reply to the traceroute probes - that's allowed
2 "Host is down" suggests the DSL router's WAN link is down or for some other reason (also lost its default route?) it doesn't know where to forward the traceroute probes. -
I'm posting this connected through the DSL router. So I know for a fact the router is working great.
Here's traceroute from my laptop attached to one of the other ports on the DSL router:
C:\Users\Administrator>tracert 8.8.8.8
Tracing route to google-public-dns-a.google.com [8.8.8.8]
over a maximum of 30 hops:1 <1 ms <1 ms <1 ms 192.168.2.1
2 45 ms 45 ms 43 ms 10.39.5.1
3 50 ms 50 ms 49 ms at-3-2-0-1715.LAX01-CORE-RTR2.verizon-gni.net [1
30.81.194.2]
4 50 ms 51 ms 125 ms so-1-1-1-0.LAX01-BB-RTR2.verizon-gni.net [130.81
.16.130]
5 54 ms 51 ms 51 ms 0.so-6-0-0.XT2.LAX9.ALTER.NET [152.63.10.157]
6 122 ms 121 ms 121 ms 0.so-1-0-0.XT2.NYC4.ALTER.NET [152.63.64.126]
7 128 ms 133 ms 137 ms TenGigE0-7-0-0.GW8.NYC4.ALTER.NET [152.63.22.45]8 128 ms 127 ms 129 ms Internet-gw.customer.alter.net [152.179.72.66]
9 128 ms 129 ms 129 ms 72.14.238.232
10 122 ms 119 ms 133 ms 209.85.252.2
11 131 ms 132 ms 130 ms 72.14.239.93
12 126 ms 127 ms 129 ms 72.14.236.200
13 142 ms 143 ms 129 ms 216.239.49.145
14 129 ms 129 ms 128 ms google-public-dns-a.google.com [8.8.8.8]Trace complete.
-
Can you show a picture of your WAN interface configuration page? The one connected to your DSL modem??
-
Here are printscreens of both my Interface and Gateway setup for the WAN.
-
Your gateway cannot be the same as the IP on its own interface.
-
SORRY ABOUT THAT! Slight oversight the last time I reset to defaults. >_<
I've set it to the proper 192.168.2.1 now. (which it always has been except for the very last time I was setting it back up in a hurry and didn't pay attention). =/
Ok, so with that properly in place this is the situation:
Still can't get a connection THROUGH pfSense. (even though it seems to be FULLY communicating over both the WAN port and the LAN port).
When I run a traceroute from PFSENSE this is what I get:
netstat -rn -f inet; traceroute -n 8.8.8.8
Routing tablesInternet:
Destination Gateway Flags Refs Use Netif Expire
default 192.168.2.1 UGS 0 19379 em2
4.2.2.2 192.168.2.2 UHS 0 14429 em2
10.39.5.1 192.168.2.1 UGHS 0 172195 em2
127.0.0.1 link#12 UH 0 10979 lo0
192.168.2.0/24 link#7 U 0 1989 em2
192.168.2.2 link#7 UHS 0 0 lo0
192.168.168.0/24 link#5 U 0 18742 em0
192.168.168.1 link#5 UHS 0 0 lo0
traceroute to 8.8.8.8 (8.8.8.8), 64 hops max, 52 byte packets
1 192.168.2.1 1.178 ms 0.298 ms 0.274 ms
2 10.39.5.1 41.901 ms 40.120 ms 39.915 ms
3 130.81.194.2 48.084 ms 48.009 ms 47.786 ms
4 130.81.16.130 52.014 ms 47.993 ms 48.036 ms
5 152.63.112.49 48.072 ms 48.021 ms 48.001 ms
6 152.63.64.126 113.913 ms 113.986 ms 114.065 ms
7 152.63.21.125 125.921 ms
152.63.16.125 134.030 ms
152.63.21.65 116.058 ms
8 152.179.72.66 127.841 ms 126.109 ms 127.908 ms
9 209.85.255.68 114.056 ms 116.028 ms
72.14.232.244 118.041 ms
10 209.85.251.37 127.852 ms
209.85.252.2 130.120 ms 130.018 ms
11 72.14.239.93 127.940 ms 128.042 ms 127.902 ms
12 72.14.236.200 126.165 ms 123.836 ms 125.851 ms
13 216.239.49.145 126.229 ms 125.828 ms 125.908 ms
14 8.8.8.8 124.284 ms 125.769 ms 128.827 msWhen I run a ping from pfSense this is what I get:
Ping output:
PING 8.8.8.8 (8.8.8.8) from 192.168.2.2: 56 data bytes
64 bytes from 8.8.8.8: icmp_seq=0 ttl=54 time=125.634 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=54 time=124.157 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=54 time=125.198 ms–- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 124.157/124.996/125.634/0.620 msBut when I run a traceroute from my COMPTUER I get:
C:\Users\Administrator>tracert 8.8.8.8Tracing route to 8.8.8.8 over a maximum of 30 hops
1 <1 ms <1 ms <1 ms 192.168.168.1
2 * * * Request timed out.
3 * * * Request timed out.
4 * * * Request timed out.
5 * * * Request timed out.
6 * * * Request timed out.
7 * ^CI also can't ping, or make any other connection to the outside world.
And AGAIN still not showing ANY states or ANYTHING in the firewall logs (even with logging turned on for the default rule. It won't even show what it's NOT blocking. It's just empty as always.)
-
Ok, so check this out as well…
I'm connect to the LAN port, so I'm testing pings on my laptop THROUGH pfSense and this is what I get:
C:\Users\Administrator>ping 192.168.2.1
Pinging 192.168.2.1 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.Ping statistics for 192.168.2.1:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),C:\Users\Administrator>ping 192.168.2.2
Pinging 192.168.2.2 with 32 bytes of data:
Reply from 192.168.2.2: bytes=32 time<1ms TTL=64
Reply from 192.168.2.2: bytes=32 time<1ms TTL=64
Reply from 192.168.2.2: bytes=32 time<1ms TTL=64
Reply from 192.168.2.2: bytes=32 time<1ms TTL=64Ping statistics for 192.168.2.2:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0msC:\Users\Administrator>ping 192.168.168.1
Pinging 192.168.168.1 with 32 bytes of data:
Reply from 192.168.168.1: bytes=32 time<1ms TTL=64
Reply from 192.168.168.1: bytes=32 time<1ms TTL=64
Reply from 192.168.168.1: bytes=32 time<1ms TTL=64
Reply from 192.168.168.1: bytes=32 time<1ms TTL=64Ping statistics for 192.168.168.1:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0msC:\Users\Administrator>ping 8.8.8.8
Pinging 8.8.8.8 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.Ping statistics for 8.8.8.8:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),So it'll respond to a ping on the port I'm directly connected to AND pass the ping along to the WAN interface, BUT it won't let anything past it. =/
-
I skimmed your posts but didn't see so hope this isn't redundant…
What do your outbound LAN rules and outbound port rules look like?
-
They're the factory defaults for right now. Since I've reset everything.
The ONLY thing I've changed on the rules is that I turned logging on for the "Default allow LAN to any rule".
Attached are some printscreens.
-
On the /firewall_nat_out.php page-
Try choosing "Manual Outbound NAT rule generation" save and see what results you get…
Assuming also that you have unchecked the last two boxes on your WAN interface page... "Block Private Networks" and "Block bogon networks" Gotta ask... ;)
-
Had just blocking of Bogons checked, so I unchecked it.
Blocking of local addresses was already UNCHECKED cause I know that with these DSL connections they're using local IPs so I wouldn't want that checked.
I turned on manual NAT out as you suggested and attached is a printscreen of what that looks like now.
I'm still having the same results.
-
My next step would be to verify that (say) a ping from LAN client computer to 8.8.8.8 was getting to the pfSense LAN interface. (Packet capture on the LAN interface, displaying just traffic to selected destination.)
If you don't see the traffic in the packet capture then I would look at the IP configuration of the client: Does it have the correct IP address for its default gateway? (Should be the IP address of the pfSense LAN interface.) Does it have the correct MAC address for that IP address?
-
Packet captured pings from laptop through the LAN interface (which all came back as "Request timed out." on my laptop) and this is what the capture looks like:
16:38:32.824386 00:1b:38:62:d0:1a (oui Unknown) > 54:04:a6:f3:2b:05 (oui Unknown), ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 128, id 29038, offset 0, flags [none], proto ICMP (1), length 60)
192.168.168.100 > google-public-dns-a.google.com: ICMP echo request, id 1, seq 117, length 40
16:38:37.490298 00:1b:38:62:d0:1a (oui Unknown) > 54:04:a6:f3:2b:05 (oui Unknown), ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 128, id 29085, offset 0, flags [none], proto ICMP (1), length 60)
192.168.168.100 > google-public-dns-a.google.com: ICMP echo request, id 1, seq 118, length 40
16:38:42.490628 00:1b:38:62:d0:1a (oui Unknown) > 54:04:a6:f3:2b:05 (oui Unknown), ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 128, id 29122, offset 0, flags [none], proto ICMP (1), length 60)
192.168.168.100 > google-public-dns-a.google.com: ICMP echo request, id 1, seq 119, length 40
16:38:47.490840 00:1b:38:62:d0:1a (oui Unknown) > 54:04:a6:f3:2b:05 (oui Unknown), ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 128, id 29150, offset 0, flags [none], proto ICMP (1), length 60)
192.168.168.100 > google-public-dns-a.google.com: ICMP echo request, id 1, seq 120, length 40As for the MAC addresses: I checked my arp tables on my laptop and all of the correct MAC addresses show as being associated with the correct IP addresses for both the WAN and LAN interfaces. So everything is good there.
-
So now with the same ping running, does a packet capture on the WAN interface show the ping leaving the pfSense box? If so, what is the source IP address?
-
Interface set to WAN, Host set to 8.8.8.8, Full detail, Reverse DNS Lookup turned OFF:
18:01:55.094629 54:04:a6:f3:2b:07 > 00:26:62:1b:09:87, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 127, id 4003, offset 0, flags [none], proto ICMP (1), length 60)
192.168.168.100 > 8.8.8.8: ICMP echo request, id 1, seq 133, length 40
18:01:59.796664 54:04:a6:f3:2b:07 > 00:26:62:1b:09:87, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 127, id 4006, offset 0, flags [none], proto ICMP (1), length 60)
192.168.168.100 > 8.8.8.8: ICMP echo request, id 1, seq 134, length 40
18:02:04.795955 54:04:a6:f3:2b:07 > 00:26:62:1b:09:87, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 127, id 4009, offset 0, flags [none], proto ICMP (1), length 60)
192.168.168.100 > 8.8.8.8: ICMP echo request, id 1, seq 135, length 40
18:02:09.795179 54:04:a6:f3:2b:07 > 00:26:62:1b:09:87, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 127, id 4013, offset 0, flags [none], proto ICMP (1), length 60)
192.168.168.100 > 8.8.8.8: ICMP echo request, id 1, seq 136, length 40Interface set to WAN, Host set to 8.8.8.8, Full detail, Reverse DNS Lookup turned ON:
18:03:26.746456 54:04:a6:f3:2b:07 (oui Unknown) > 00:26:62:1b:09:87 (oui Unknown), ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 127, id 4104, offset 0, flags [none], proto ICMP (1), length 60)
192.168.168.100 > google-public-dns-a.google.com: ICMP echo request, id 1, seq 137, length 40
18:03:31.294265 54:04:a6:f3:2b:07 (oui Unknown) > 00:26:62:1b:09:87 (oui Unknown), ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 127, id 4109, offset 0, flags [none], proto ICMP (1), length 60)
192.168.168.100 > google-public-dns-a.google.com: ICMP echo request, id 1, seq 138, length 40
18:03:36.293619 54:04:a6:f3:2b:07 (oui Unknown) > 00:26:62:1b:09:87 (oui Unknown), ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 127, id 4115, offset 0, flags [none], proto ICMP (1), length 60)
192.168.168.100 > google-public-dns-a.google.com: ICMP echo request, id 1, seq 139, length 40
18:03:41.293819 54:04:a6:f3:2b:07 (oui Unknown) > 00:26:62:1b:09:87 (oui Unknown), ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 127, id 4118, offset 0, flags [none], proto ICMP (1), length 60)
192.168.168.100 > google-public-dns-a.google.com: ICMP echo request, id 1, seq 140, length 40192.168.168.100 is of course my laptop's IP address (where the pings are coming from).
-
I would really like to know where traffic is stopping inside pfSense. The above shows that it's tracking and trafficking my echo-requests…. but no echo-replies whatsoever. Just doesn't make sense.
Like check this out... INSIDE pfSense >> Diagnostics >> Ping: I set the interface to my WAN and tell it to ping 8.8.8.8 while I packet capture the WAN interface for the host address 192.168.168.2 (the WAN interface's ip address) and this is what I get:
18:29:04.862197 54:04:a6:f3:2b:07 > 00:26:62:1b:09:87, ethertype IPv4 (0x0800), length 94: (tos 0x0, ttl 64, id 54046, offset 0, flags [none], proto ICMP (1), length 80)
192.168.2.2 > 10.39.5.1: ICMP echo request, id 33034, seq 3411, length 60
18:29:04.907335 00:26:62:1b:09:87 > 54:04:a6:f3:2b:07, ethertype IPv4 (0x0800), length 94: (tos 0x0, ttl 126, id 54046, offset 0, flags [none], proto ICMP (1), length 80)
10.39.5.1 > 192.168.2.2: ICMP echo reply, id 33034, seq 3411, length 60
18:29:05.862197 54:04:a6:f3:2b:07 > 00:26:62:1b:09:87, ethertype IPv4 (0x0800), length 94: (tos 0x0, ttl 64, id 7269, offset 0, flags [none], proto ICMP (1), length 80)
192.168.2.2 > 10.39.5.1: ICMP echo request, id 33034, seq 3667, length 60
18:29:05.905440 00:26:62:1b:09:87 > 54:04:a6:f3:2b:07, ethertype IPv4 (0x0800), length 94: (tos 0x0, ttl 126, id 7269, offset 0, flags [none], proto ICMP (1), length 80)
10.39.5.1 > 192.168.2.2: ICMP echo reply, id 33034, seq 3667, length 60
18:29:06.862202 54:04:a6:f3:2b:07 > 00:26:62:1b:09:87, ethertype IPv4 (0x0800), length 94: (tos 0x0, ttl 64, id 5674, offset 0, flags [none], proto ICMP (1), length 80)
192.168.2.2 > 10.39.5.1: ICMP echo request, id 33034, seq 3923, length 60
18:29:06.905499 00:26:62:1b:09:87 > 54:04:a6:f3:2b:07, ethertype IPv4 (0x0800), length 94: (tos 0x0, ttl 126, id 5674, offset 0, flags [none], proto ICMP (1), length 80)
10.39.5.1 > 192.168.2.2: ICMP echo reply, id 33034, seq 3923, length 60
18:29:07.862204 54:04:a6:f3:2b:07 > 00:26:62:1b:09:87, ethertype IPv4 (0x0800), length 94: (tos 0x0, ttl 64, id 21147, offset 0, flags [none], proto ICMP (1), length 80)
192.168.2.2 > 10.39.5.1: ICMP echo request, id 33034, seq 4179, length 60
18:29:07.907530 00:26:62:1b:09:87 > 54:04:a6:f3:2b:07, ethertype IPv4 (0x0800), length 94: (tos 0x0, ttl 126, id 21147, offset 0, flags [none], proto ICMP (1), length 80)
10.39.5.1 > 192.168.2.2: ICMP echo reply, id 33034, seq 4179, length 60
18:29:08.069025 54:04:a6:f3:2b:07 > 00:26:62:1b:09:87, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 35388, offset 0, flags [none], proto ICMP (1), length 84)
192.168.2.2 > 8.8.8.8: ICMP echo request, id 22433, seq 0, length 64
18:29:08.199553 00:26:62:1b:09:87 > 54:04:a6:f3:2b:07, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 54, id 19673, offset 0, flags [none], proto ICMP (1), length 84)
8.8.8.8 > 192.168.2.2: ICMP echo reply, id 22433, seq 0, length 64
18:29:08.862208 54:04:a6:f3:2b:07 > 00:26:62:1b:09:87, ethertype IPv4 (0x0800), length 94: (tos 0x0, ttl 64, id 50512, offset 0, flags [none], proto ICMP (1), length 80)
192.168.2.2 > 10.39.5.1: ICMP echo request, id 33034, seq 4435, length 60
18:29:08.909580 00:26:62:1b:09:87 > 54:04:a6:f3:2b:07, ethertype IPv4 (0x0800), length 94: (tos 0x0, ttl 126, id 50512, offset 0, flags [none], proto ICMP (1), length 80)
10.39.5.1 > 192.168.2.2: ICMP echo reply, id 33034, seq 4435, length 60
18:29:09.069780 54:04:a6:f3:2b:07 > 00:26:62:1b:09:87, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 3448, offset 0, flags [none], proto ICMP (1), length 84)
192.168.2.2 > 8.8.8.8: ICMP echo request, id 22433, seq 1, length 64
18:29:09.199595 00:26:62:1b:09:87 > 54:04:a6:f3:2b:07, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 54, id 19674, offset 0, flags [none], proto ICMP (1), length 84)
8.8.8.8 > 192.168.2.2: ICMP echo reply, id 22433, seq 1, length 64
18:29:09.862210 54:04:a6:f3:2b:07 > 00:26:62:1b:09:87, ethertype IPv4 (0x0800), length 94: (tos 0x0, ttl 64, id 25233, offset 0, flags [none], proto ICMP (1), length 80)
192.168.2.2 > 10.39.5.1: ICMP echo request, id 33034, seq 4691, length 60
18:29:09.907438 00:26:62:1b:09:87 > 54:04:a6:f3:2b:07, ethertype IPv4 (0x0800), length 94: (tos 0x0, ttl 126, id 25233, offset 0, flags [none], proto ICMP (1), length 80)
10.39.5.1 > 192.168.2.2: ICMP echo reply, id 33034, seq 4691, length 60
18:29:10.070764 54:04:a6:f3:2b:07 > 00:26:62:1b:09:87, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 16652, offset 0, flags [none], proto ICMP (1), length 84)
192.168.2.2 > 8.8.8.8: ICMP echo request, id 22433, seq 2, length 64
18:29:10.199526 00:26:62:1b:09:87 > 54:04:a6:f3:2b:07, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 54, id 19675, offset 0, flags [none], proto ICMP (1), length 84)
8.8.8.8 > 192.168.2.2: ICMP echo reply, id 22433, seq 2, length 64
18:29:10.862211 54:04:a6:f3:2b:07 > 00:26:62:1b:09:87, ethertype IPv4 (0x0800), length 94: (tos 0x0, ttl 64, id 35094, offset 0, flags [none], proto ICMP (1), length 80)
192.168.2.2 > 10.39.5.1: ICMP echo request, id 33034, seq 4947, length 60
18:29:10.907478 00:26:62:1b:09:87 > 54:04:a6:f3:2b:07, ethertype IPv4 (0x0800), length 94: (tos 0x0, ttl 126, id 35094, offset 0, flags [none], proto ICMP (1), length 80)
10.39.5.1 > 192.168.2.2: ICMP echo reply, id 33034, seq 4947, length 60
18:29:11.862212 54:04:a6:f3:2b:07 > 00:26:62:1b:09:87, ethertype IPv4 (0x0800), length 94: (tos 0x0, ttl 64, id 36592, offset 0, flags [none], proto ICMP (1), length 80)
192.168.2.2 > 10.39.5.1: ICMP echo request, id 33034, seq 5203, length 60
18:29:11.905614 00:26:62:1b:09:87 > 54:04:a6:f3:2b:07, ethertype IPv4 (0x0800), length 94: (tos 0x0, ttl 126, id 36592, offset 0, flags [none], proto ICMP (1), length 80)
10.39.5.1 > 192.168.2.2: ICMP echo reply, id 33034, seq 5203, length 60So it's showing that when I tell the WAN to send off data, IT DOES and TRACKS IT! But if I try to send data THROUGH pfSense (from the LAN to the WAN) I get nothing. Just does not make sense.
-
You have turned off NAT in pfSense (at least for LAN to WAN traffic). If NAT was turned on the source address (as seen at the WAN interface) for the ping to 8.8.8.8 would be the pfSense WAN IP address.
I suspect your ADSL router doesn't have a route to the subnet of the pfSense LAN interface hence it doesn't know on which interface to forward packets with destinaion IP address 192.168.168.100.
You should turn NAT on in pfSense or add an appropriate route to your ADSL router.
-
Well, I've turned Dynamic Routing Version 2 ON in my DSL router.
And I renabled automatic NAT again in pfSense (since turning it to manual didn't make a difference).
Is there anything else I need to enable in pfSense in order for it to send RIP data back and forth between the two routers?
While I was remoted in to my laptop (using LogMeIn) I switched it back over to use the pfSense as it's default gateway and lost my connection and can't get it back (which I expected). So obviously traffic still isn't flowing through it. I'll have to continue work on this tomorrow morning since I'm at home now.
-
Can you put the modem in bridge mode and let the router do the login?
-
Thank you for any and all help in setting up my equipment. If setting my dsl router to bridge mode will simplify, speed up, make more stable or just all around better my connection I will be more than happy do it.
Now, please don't take this the wrong way as me being rude, I just want this post to get back on track… so I'll reiterate:
It's not my equipment that is the issue here.
I AM HAVING THE SAME PROBLEM WITH 1 DSL LINE WITH A ROUTER, 1 T1 LINE USING AN ADTRAN CSU/DSU, AND 1 T1 LINE USING A CISCO CSU/DSU TESTED WITH ANY AND ALL PORTS ON MY PFSENSE.ALL DO NOT WORK. ALL WITH THE SAME EXACT SYMPTONS.
It is NOT equipment OR how I've configured pfSense. I've had pfSense up and running perfectly fine countless times. It works great. The problem is that out of no where when I've reset states one too many times it breaks and NEVER COMES BACK... that is UNTIL I COMPLETELY REINSTALL PFSENSE. <<=== That is the issue. There is a bug somewhere. I want to know where and I want to know if there's a way to fix it without me having to re-install the entire program entirely. Because currently re-installation is the ONLY way I have been successful in getting pfSense to work properly again.
So again: I can't communicate THROUGH pfSense with ANY equipment I plug on the other side of it. Communication FROM pfSense itself works great! But THROUGH it doesn't. <<=== AND ALL OF THIS IS ONLY AFTER PFSENSE BREAKS. After I've had everything setup and working hunky-dory and then I tweak a few firewall rules, reset states one too many times and BAM! Broke and unreparable (unless someone can help me find the broken part and fix it).
Again, please don't take offense, I just want to keep my eye on the prize.
-
No worries- I guess I missed any mention of you resetting states to make this happen…. I did lose my glasses so need new ones...
But the DSL modem bridge comment... Im of the opinion that you shouldn't double NAT unless there is no other way... Bridge mode just keeps it simpler...
In my case- Ive reset states here quite often and guess Ill go back and read more about resetting states and see if I can reproduce it here...
Id be curious what your MBUF is at...
And how many states your machine maxes out at...
-
Well, I've turned Dynamic Routing Version 2 ON in my DSL router.
Why?
Is there anything else I need to enable in pfSense in order for it to send RIP data back and forth between the two routers?
Considering the difficulty you have had so far, why would that be a better solution than adding a static route to your DSL router or NATing in pfSense or adopting chpalmer's suggestion of using your DSL router in bridge mode?
While I was remoted in to my laptop (using LogMeIn) I switched it back over to use the pfSense as it's default gateway and lost my connection and can't get it back (which I expected).
Did you expect to lose your connection because your analysis of traffic paths showed a problem in that configuration or did you expect to lose the connection because your experience has shown you the network was fragile over configuration changes?
So obviously traffic still isn't flowing through it. I'll have to continue work on this tomorrow morning since I'm at home now.
What approach will you adopt for solving this?
Thank you for any and all help in setting up my equipment. If setting my dsl router to bridge mode will simplify, speed up, make more stable or just all around better my connection I will be more than happy do it.
DSL router in bridge mode is an option but depending on how the other equipment that connects you to the internet behaves you might might want to adopt a different approach.
It is NOT equipment OR how I've configured pfSense. I've had pfSense up and running perfectly fine countless times. It works great. The problem is that out of no where when I've reset states one too many times it breaks and NEVER COMES BACK… that is UNTIL I COMPLETELY REINSTALL PFSENSE. <<=== That is the issue. There is a bug somewhere. I want to know where and I want to know if there's a way to fix it without me having to re-install the entire program entirely. Because currently re-installation is the ONLY way I have been successful in getting pfSense to work properly again.
As best I can tell you need NAT in pfSense to pass traffic through since your DSL router doesn't seem to have a route to the LAN subnet downstream of pfSense. Somehow NAT was disabled in pfSense. Presumably as a consequence of a "few" firewall rule tweaks. I have no reason to believe that n+1 (n currently unknown) firewall state resets will disable NAT. Depending on what you call a firewall rule tweak (some action you get to through the firewall menu?) a firewall rule tweak can disable NAT.
Again, please don't take offense, I just want to keep my eye on the prize.
OK, I promise not to take offence. Please do the same for me.
I think the best ways you can accomplish your goal and help the pfSense project is to
1. keep detailed notes on what you do and the consequences of change. I doubt any readers of these forums have the time or interest to do a random sequence of state table resets and firewall rule tweaks in the hope of chancing upon the same sequence you claim causes your problems. Without knowing what you did no-one can say for any certainty if the system is behaving correctly or you have found a bug.
2. Before making a change answer the question "Why will this change make the behaviour I'm looking for?" If you can't answer that you shouldn't be making the change. If the change "doesn't work" find out why it doesn't work before making further changes. This will help you avoid making the same futile change in the future.
3. Take small steps and test changes carefully so you can easily go back to a working configuration. If necessary, backup your pfSense configuration frequently and document the features of that backed up configuration. In most cases you should be able to recover desired behaviour by restoring a saved configuration file and rebooting.
4. Read a few articles (e.g. from Wikipedia or a good IP networking textbook) on IP routing and NAT. With three different connections to the internet through three different pieces of equipment it is quite possible you will not be able to replicate configuration for one WAN interface onto another. Future troubleshooting will probably be eased if you understand how each device connecting to the internet is supposed to behave.
That's probably enough for now.
-
But the DSL modem bridge comment… Im of the opinion that you shouldn't double NAT unless there is no other way... Bridge mode just keeps it simpler...
I'm fine with that recommendation. But considering the multiple WAN interfaces proposed I would strongly recommend the "no other way" issue be settled by analysis rather than trying a few "firewall rule tweaks".
-
Just to chime in here. I agree that double NAT is best avoided but it only gives trouble in rare circumstances. I have run double NAT for months with no problems at all.
This is not a double NAT problem.You don't seem to have fully explored the packet capture that showed that pfSense was not NATing traffic. Simply switching from auto to manual should not stop NAT working. You would have to deliberately remove the NAT rules.
Switch it back to auto, I would reboot the box at this point, then rerun your packet captures to demonstrate that NAT is working.Also unexplained is the fact that you somehow ended up without a default route? :-\
Going right back to the beginning; is it a specific set of configuration changes that cause pfSense to stop forwarding traffic or simply making too many changes of any sort?
Steve