Update pfsense 2.0.1 stable to 2.1 problem with routes
-
Hi, actually I am upgrade the pfsense 2.0.1 stable to 2.1 throught web panel. All ok, but the route static not found…In the command line option 8, I exec netstat -ar and the routes are ok. Launch ping from pfsense to ip routing and OK. But the problem is the host in the lan, when ping to ip routing, not works...
Pfsense is restart the update, I may have to make another reboot ... Prior to this worked perfectly routes. Sorry for my english.
Thanks in advanced.
-
Please give examples of ping from pfSense that works and ping from host on LAN that does not work. Post your LAN subnet, pfSense LAN IP, LAN rules, and WAN settings (static or DHCP, or PPPoE…).
It sounds like your WAN internet is working from pfSense, but it does not work from a host on the LAN. Is that correct? -
Yes, If correct. Example:
LAN: 10.0.0.1/16
ROUTES:
NETWORK: 192.168.1.0/16
netstat -ar
192.168.1.0/16 10.0.0.4 UGS 0 0 em0
The ip 192.168.1.20.is ip to remote VPN ipsec, but I add route in my linux, and works fine.
EXAMPLES:
PING FROM PFSENSE:
[2.1-RELEASE][admin@pfsense]/root(6): ping 192.168.1.20
PING 192.168.1.20 (192.168.1.20): 56 data bytes
64 bytes from 192.168.1.20: icmp_seq=2 ttl=127 time=34.671 ms
64 bytes from 192.168.1.20: icmp_seq=3 ttl=127 time=31.521 ms
64 bytes from 192.168.1.20: icmp_seq=4 ttl=127 time=30.963 ms
64 bytes from 192.168.1.20: icmp_seq=5 ttl=127 time=22.719 ms
^C
–- 192.168.1.20 ping statistics ---
6 packets transmitted, 4 packets received, 33.3% packet loss
round-trip min/avg/max/stddev = 22.719/29.968/34.671/4.418 msTRACEROUTE FROM PFSENSE TO HOST ROUTE:
[2.1-RELEASE][admin@pfsense]/root(7): traceroute 192.168.1.20
traceroute to 192.168.1.20 (192.168.1.20), 64 hops max, 52 byte packets
1 10.0.0.4 (10.0.0.4) 7.204 ms 8.604 ms 7.758 ms
2 192.168.1.20 (192.168.1.20) 25.165 ms 76.467 ms 25.152 msPING TO HOST FROM HOST LAN(Opensuse), MY PC FOR EXAMPLE:
linux-r1m0:~ # ping 192.168.1.20
PING 192.168.1.20 (192.168.1.20) 56(84) bytes of data.linux-r1m0:~ # traceroute 192.168.1.20
traceroute to 192.168.1.20 (192.168.1.20), 30 hops max, 40 byte packets using UDP
1 ip_isp (ip_isp) 9.503 ms 8.405 ms 7.266 ms
2 ip_isp (62.14.37.53) 6.195 ms 6.098 ms 4.926 ms
3 192.168.66.121 (192.168.66.121) 5.748 ms 4.644 ms 5.577 ms
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *linux-r1m0:~ # route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.0.0.1 0.0.0.0 UG 0 0 0 eth0
10.0.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0Here show how pfsense not routing the traffic to host…And before update 2.0.1 to 2.1, works fine.
Pfsense not routing works...
Can I help me?
Reboot the pfsense and not working. I quit the route, and created again and not works...
-
I have a 2.1-RELEASE system with a static route that goes across LAN to another test router, and that is working (attached).
Your "netstat -ar" reports a route for 192.168.1.0/16 - that is an unusual way to say it.
Should it be:
192.168.0.0/16 or
192.168.1.0/24?Post your pfSense static route screen, and the pfSense Diagnostics->Routes.
Edit: attachment added.
-
Thanks for all.
I will not put the picture, because I will not show my internal range ips. I'm just saying that worked perfectly, and now does not work any of the routes, we have many more. What a coincidence that does not work any not? If I raise the old backup pfsense I did, pulling smoothly … Ummm maybe I should install pfsense 2.1 stable from 0 instead of doing the upgrade not you think?
Thanks.
-
Ummm maybe I should install pfsense 2.1 stable from 0 instead of doing the upgrade not you think?
Pretty much valid point for any OS out there.
-
I'd ALWAYS opt for a fresh install where possible for ANY OS, including pfsense over upgrading. That said, I'll be forced to upgrade on at least one distant machine running in ESXi soon and I'm looking forward to being locked out :o
-
I will not put the picture, because I will not show my internal range ips.
Internal private IPv4 address space IPs are just that - nobody can route to them across the real internet, so they cannot be used by outsiders reading the board trying to attack your site, DOS your site…
At this point of fault-finding, if you need more help, then the fine detail of your network and settings is needed. Otherwise we are just guessing what might or might not be the problem. -
I have made to detail like this but with other internal ips, but the argument is the same do not you think? give that more do not understand … If I work before and after the update no. Especially since it is a matter of ROUTES, get it done any firewall, even a desktop linux or even windows ... do not understand anything ... I'm sure I do an installation DeSade 0 of version 2.1 stable and runs smoothly
Is more, even going further, we have another firewall in production specifically for servers and those routes work perfectly if I wear that as a gateway server, is not it already pretty rare? Something in the update has fucked up, we're talking about routes ...
Thanks anyway.
-
Yeah, don't use upgrades. Do a clean install. Especially when it takes minutes.
-
wow now I have installed pfsense 2.1 stable from 0, install clean, and the routes not found…
I dont understand...
-
Ummmmm… routes not found.
Can you give me another example of what you are trying to do.
What is the IP of the first computer and what is the IP of the second computer you are trying to ping?
-
Thanks for your reply and interesting.
LAN: 10.0.0.1/16
ROUTES:
NETWORK: 192.168.1.0/16
netstat -ar
192.168.1.0/16 10.0.0.4 UGS 0 0 em0
The ip 192.168.1.20.is ip to remote(route), but I add route in my linux, and works fine.
EXAMPLES:
PING FROM PFSENSE:
[2.1-RELEASE][admin@pfsense]/root(6): ping 192.168.1.20
PING 192.168.1.20 (192.168.1.20): 56 data bytes
64 bytes from 192.168.1.20: icmp_seq=2 ttl=127 time=34.671 ms
64 bytes from 192.168.1.20: icmp_seq=3 ttl=127 time=31.521 ms
64 bytes from 192.168.1.20: icmp_seq=4 ttl=127 time=30.963 ms
64 bytes from 192.168.1.20: icmp_seq=5 ttl=127 time=22.719 ms
^C
–- 192.168.1.20 ping statistics ---
6 packets transmitted, 4 packets received, 33.3% packet loss
round-trip min/avg/max/stddev = 22.719/29.968/34.671/4.418 msTRACEROUTE FROM PFSENSE TO HOST ROUTE:
[2.1-RELEASE][admin@pfsense]/root(7): traceroute 192.168.1.20
traceroute to 192.168.1.20 (192.168.1.20), 64 hops max, 52 byte packets
1 10.0.0.4 (10.0.0.4) 7.204 ms 8.604 ms 7.758 ms
2 192.168.1.20 (192.168.1.20) 25.165 ms 76.467 ms 25.152 msPING TO HOST FROM HOST LAN(Opensuse), MY PC FOR EXAMPLE:
linux-r1m0:~ # ping 192.168.1.20
PING 192.168.1.20 (192.168.1.20) 56(84) bytes of data.linux-r1m0:~ # traceroute 192.168.1.20
traceroute to 192.168.1.20 (192.168.1.20), 30 hops max, 40 byte packets using UDP
1 ip_isp (ip_isp) 9.503 ms 8.405 ms 7.266 ms
2 ip_isp (62.14.37.53) 6.195 ms 6.098 ms 4.926 ms
3 192.168.66.121 (192.168.66.121) 5.748 ms 4.644 ms 5.577 ms
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *linux-r1m0:~ # route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.0.0.1 0.0.0.0 UG 0 0 0 eth0
10.0.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0In pfsenes 2.0.3 stable works fine….
-
More info, the host 10.0.0.4 is a linux which is connected to a vp. The remote IP of the vpn where I have to get is ip 192.168.1.20
Simple:
LAN PFSENSE: 10.0.0.1
LAN LINUX WHICH CONNECTED TO REMOTE VPN: 10.0.0.4
IP LOCAL TUNNEL VPN THAT CONNECTED LINUX MACHINE: 192.168.1.20I have add first gateway 10.0.0.4. When in routes, add that to reach the IP 192.168.1.20, pull the connection from 10.10.0.4.
In pfsense 2.0.3 works fine.
Is more, I have a pfsense 2.0.3 in production if I put the IP gateway, the network came through 10.0.0.4 192.168.1.20 without problems … do not understand what is the problem if a simple ROUTE! !
-
Do you have firewall rules to allow all this?
And what is the VPN type?
-
I've never had to add any rules to establish pfsense routes … But still, I tried to add that whatever comes from pfsense network ip 192.168.1.20 bound to use the 10.0.0.4 gateway and even with those. well .. There is a big bug because I'm looking at all options for the new pfsense 2.1 stable (install from scratch) and I see nothing. It's a simple route god!
-
Where is this VPN running and what kind of VPN is it?
-
where is the ip is 10.100.100.4 vpn, I said before the 10.0.0.4 for not posting the actual ip security of our network. In linux machine the vpn type is vpnc, but that's not important because it used to work on the other pfsense, is a route again.
I will flash images, even my real internal ips how desperate I am that I understand nothing.
ADD GATEWAY:
http://imageshack.us/photo/my-images/10/bzd7.png/
ADD ROUTE:
http://imageshack.us/photo/my-images/30/16c.png/
just in case, I added up a rule in pfsense lan but does not work well
http://imageshack.us/photo/my-images/545/f487.png/
repeat in pfsense 2.0.1 this works
-
the ip where I want to end, is 192.168.1.20, this in the linux server, 10.100.100.4, I mean right?
Sorry for my english.
Thanks for all.
-
Trying to route in and out of the same interface.
The firewall rule you would need is:
source: LANnet destination: 192.168.1.20 allow gateway: system default10.100.100.4 is not in the 10.0.0.1/16 subnet
Steve
-
10.0.0.1/16 network that I commented that it was fictional, it was not real, was to simulate my local network to not put my ips internal rank for SAFETY!
IP REAL:
LAN PFSENSE: 10.100.100.3
IP LINUX VPNC: 10.100.100.4
IP where I'm going, which is connected to the vpn 10.100.100.4: 192.168.1.20http://imageshack.us/photo/my-images/853/9b7f.png/
clearer the water …
-
Is more, from pfsense if I get to the IP 192.168.1.20
[2.1-RELEASE][root@pfsense-mo2o-ketchum.mo2o.com]/root(1): ping 192.168.1.20
PING 192.168.1.20 (192.168.1.20): 56 data bytes
64 bytes from 192.168.1.20: icmp_seq=2 ttl=127 time=50.328 ms
64 bytes from 192.168.1.20: icmp_seq=3 ttl=127 time=46.436 ms
64 bytes from 192.168.1.20: icmp_seq=4 ttl=127 time=43.714 ms
64 bytes from 192.168.1.20: icmp_seq=5 ttl=127 time=46.687 msIs more:
netstat -ar return:
192.168.1.20/32 10.100.100.4 UGS 0 6 em0
From ip host lan pfsense, for example, 10.100.100.200, try to traceroute:
root@pre:~# traceroute 192.168.1.20
traceroute to 192.168.1.20 (192.168.1.20), 30 hops max, 60 byte packets
1 isp (ip public isp) 1.534 ms 1.592 ms 1.611 ms
2 isp (ip public isp) 2.107 ms 2.199 ms 2.234 ms
3 192.168.66.121 (192.168.66.121) 2.747 ms 2.847 ms 2.868 ms^CPfsense not route working…
This routed me to the internet instead of enrutarme to 10.100.100.4 to reach 192.168.1.20, I have explained well. I think I can explain and better.
What is the problem?? I dont understand anything...
-
Is more,
I shutdown pfsense 2.1, and I turned on pfsense 2.0.1 I had a backup before performing the upgrade. And look …
root@pre:~# ping 192.168.1.20
PING 192.168.1.20 (192.168.1.20) 56(84) bytes of data.
From 10.100.100.3: icmp_seq=1 Redirect Host(New nexthop: 10.100.100.4)
64 bytes from 192.168.1.20: icmp_req=1 ttl=127 time=28.7 ms
From 10.100.100.3: icmp_seq=2 Redirect Host(New nexthop: 10.100.100.4)
64 bytes from 192.168.1.20: icmp_req=2 ttl=127 time=28.3 ms
From 10.100.100.3: icmp_seq=3 Redirect Host(New nexthop: 10.100.100.4)
64 bytes from 192.168.1.20: icmp_req=3 ttl=127 time=29.8 ms
^C
--- 192.168.1.20 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 28.399/28.989/29.840/0.616 ms
root@pre:~# traceroute 192.168.1.20
traceroute to 192.168.1.20 (192.168.1.20), 30 hops max, 60 byte packets
1 10.100.100.3 (10.100.100.3) 0.577 ms 0.600 ms 0.631 ms
2 10.100.100.4 (10.100.100.4) 0.766 ms 0.826 ms 0.897 ms
3 192.168.1.20 (192.168.1.20) 31.176 ms 31.609 ms 31.779 mscame perfectly to 192.168.1.20
BUG PFSENSE 2.1 ROUTES???
-
http://imageshack.us/photo/my-images/30/ynvc.png/
-
Not related to your issue, but is better if you attach the screenshots directly to your post reply, instead of imageshack ;)
-
Worth, and you have to see what these commenting me photo to the problem that I have … There is a piece of bug in pfsense, I assure you.
-
For the moment and to take my headaches, I have set up the backup pfsense routes 2.0.3 stable and work well. Until we solve this BUG, we will continue with this version.
-
root@pre:~# traceroute 192.168.1.20
traceroute to 192.168.1.20 (192.168.1.20), 30 hops max, 60 byte packets
1 isp (ip public isp) 1.534 ms 1.592 ms 1.611 ms
2 isp (ip public isp) 2.107 ms 2.199 ms 2.234 ms
3 192.168.66.121 (192.168.66.121) 2.747 ms 2.847 ms 2.868 ms^CWhere is the machine in this traceroute, 192.168.66.121? That is also in the 192.168.0.0/16 subnet. It's not surprising pfSense is getting confused if it can access that subnet via both gateways.
Why does ping work but traceroute doesn't. :-\ Edit: Misread that.Steve
-
Ip that is not ours, I teach a traceroute goes from pfsense 2.0.3:
[2.0.3-RELEASE] [admin@pfsense-mo2o-ketchum.mo2o.com] / root (1): traceroute 192.168.1.20
traceroute to 192.168.1.20 (192.168.1.20), 64 hops max, 52 byte packets
1 10.100.100.4 (10.100.100.4) 1,020 ms 0.615 ms 0.586 ms
2 * 192.168.1.20 (192.168.1.20) 28.836 ms 37.787 msAll ok not see? While the traffic routes. Pfsense 2.1 The problem is that when I try to get from an internal host to the ip 192.168.1.20 instead of route to 10.100.100.4, I routed to our wan. What makes it completely wrong.
It's the same rule for pfsense 2.0.3 to 2.1 that is more I tried to delete it and recreate it. Hallucinate with pfsense 2.1 not understand anything. I assure you the route is straight.
Probe a facility from 0 to pfsense 2.1 stable instead of doing an upgrade, and import the configuration xml, yet not strip.
I do not know what else to do, so as a need for programmers routes, will continue with pfsense 2.0.1 until they fix the bug, although they say it's not a bug.
Sorry for my english.
Thanks for all, true.
-
It seems very strange to me that you have a private subnet somewhere upstream of your public WAN IP.
You need to look at the pfSense routing table and see if it has somehow acquired a route to 192.168.. on the WAN. Perhaps via some new routing protocol introduced in 2.1.
Normally if you had specified a gateway in the firewall rule, and that rule is actually catching the traffic, then it can only use that gateway. However there is a background rule that will by-pass that for local networks the 'negate rule'. You can turn it off in System: Advanced: Firewall/NAT. That also existed in 2.0.3 but perhaps it didn't recognise it as local there.
In 2.0.3 do you need to have a firewall rule specifying a gateway?
Specifying a gateway on the same interface that the traffic arrives is the sort of thing that can fail to work. See NAT reflection for example.
Steve
-
I spent alone with the IP 192.168.1.20, it happens with all routes. A little weird right? Indeed, for fanjar this topic I say I've tried to add the same routes to pfsense 2.1 BETA and I have worked flawlessly. Pfsense 2.1 if stable has a bug or if, or add something new to fuck routes because it does not work any of the 4 that I have on pfsense 2.1 stable. There is a bit weird that I work perfectly in pfsense routes 2.0.1 stable and 2.1 BETA!
Thanks for everything.
-
Same problem her. In 2.0.3 routes work fine, in 2.1 do not!
Test upgrading in place and fresh install, both not work. -
The same sort of static routes to an internal gateway?
Steve
-
Yep! two Pfsense with Wan in same network.
-
Can you specify the routes and under what conditions they don't work? For example maykel535 was able to use the route from the pfSense box itself but not from a client in the same subnet as the gateway.
Steve
-
do not compliqueis more, I can not lose more time with this because in pfsense 2.1 BETA works. Something as simple as a route, I can not lose more time. There is a bug and I just want to help you solve … A shame since pfsense 2.1 stable comes with a amount of improvements as MultiWAN dynamic dns and a bunch of bug fixes.
The real problem is that instead routes of enrutarte to the host that is, it takes you out to the wan and not because there is anything wrong, but simply routed bad this version of pfsense 2.1
We will have to wait ...
-
any officiale update or replay to this problem?
Upgrading to 2.1 in multi WAN-LAN configuration is a hell! -
I too had some routing issues from 2.03 -> 2.1. I think 2.0.3 was more forgiving with routes than 2.1. And interestingly enough, I too am running a multi-WAN.
In my configuration I have two LANs and two WANs. I want each LAN to go out a different WAN, so I created a rule with each gateway in it.
When this is set up in 2.0.3, LAN to LAN2 communication will occur without a specific rule to route traffic between them. However, I had to specifically create a rule in each LAN to route traffic between them or else it would not happen. I assume this is due to creating a rule specifying which gateway each LAN needs to use. It was pretty frustrating for a few week since the LAN serves resources up to LAN2 and vice versa.
I've attached screen shots of my new rules. But as I mentioned before, an upgrade from 2.0.3, which was working flawlessly, to 2.1 required me to troubleshoot and create new explicit rules to route traffic between my two LANs.
So for folks experiencing issues, I would recommend that you sit down and think about rewriting your rules and validating them. I had to do hours of testing to ensure that my new rules worked and didn't break anything else.
![Screen Shot 2013-10-10 at 10.11.35 AM.png](/public/imported_attachments/1/Screen Shot 2013-10-10 at 10.11.35 AM.png)
![Screen Shot 2013-10-10 at 10.11.35 AM.png_thumb](/public/imported_attachments/1/Screen Shot 2013-10-10 at 10.11.35 AM.png_thumb)
![Screen Shot 2013-10-10 at 10.11.48 AM.png](/public/imported_attachments/1/Screen Shot 2013-10-10 at 10.11.48 AM.png)
![Screen Shot 2013-10-10 at 10.11.48 AM.png_thumb](/public/imported_attachments/1/Screen Shot 2013-10-10 at 10.11.48 AM.png_thumb) -
Using OpenVPN tunnel with ovpns1, and created a route does not accept ipv6 automatically switch to ipv4 and remove.
Was not done the update version 2.0.3 is rather a new installation
-
Hi Tim,
I just added the crossing rules from LAN1 to LAN2 and viceversa, and I put them before the rule that send the traffic to a specific routing group (otherwise the intranet traffic goes out to the gateway!?!?!) but I still have problem… I will try to reset the configuration and restart, but I have 40 rules and nat with 6 interfaces, I never had problems in upgrading before :-(Alessandro