@viragomann said in Routing configuration issue between 3 interfaces on pfsense (New to pfsense): Check that twice to be sure. Than check it again... Your lan rules are by default any any so if you did not mess with that, then any devices on the lan would be able to talk any device on either of your 2 networks with no rules even on those interfaces. So as long as the device in the other vlans is pointing back to pfsense as its gateway.. Its most likely the devices firewall, or other security software on it that you didn't disable.. Simple test can device in nework A ping pfsense IPs you have listed there 10.1.2.1 and 10.1.3.1 from the 10.1.1.0 network.. If so simple do a sniff on pfsense say on network B interface - while you ping something network be at 10.1.2.x -- do you see the ping go out from pfsense.. If so then its not pfsense.. Here example.. My lan rules. My lan is 192.168.9.0/24, pfsense IP is 192.168.9.253 Another segment of mine (dmz) is 192.168.3.0/24 where pfsense IP in that is 192.168.3.253 I can ping 192.168.3.253 from my 192.168.9.100 box. $ ping 192.168.3.253 Pinging 192.168.3.253 with 32 bytes of data: Reply from 192.168.3.253: bytes=32 time<1ms TTL=64 Reply from 192.168.3.253: bytes=32 time<1ms TTL=64 Here is sniff of that 192.168.3.253 interface only for stuff going to 192.168.3.10 while I ping that ip So you see the ping go out, and in my case get a response... Do you see ping request go out.. Make sure your sniffing on pfsense B interface, while you ping from A (your lan with rules that are any any).. Just to be complete - my dmz rules do not allow pinging anything in my other networks. So while something in my dmz can ping pfs IP 192.168.3.253, can not ping pfsense IP say 192.168.9.253 root@pi-hole:/home/pi# ping 192.168.3.253 PING 192.168.3.253 (192.168.3.253) 56(84) bytes of data. 64 bytes from 192.168.3.253: icmp_seq=1 ttl=64 time=0.653 ms 64 bytes from 192.168.3.253: icmp_seq=2 ttl=64 time=0.497 ms Trying to ping 192.168.9.253 just fails.. root@pi-hole:/home/pi# ping 192.168.9.253 PING 192.168.9.253 (192.168.9.253) 56(84) bytes of data. ^C --- 192.168.9.253 ping statistics --- 10 packets transmitted, 0 received, 100% packet loss, time 9350ms

@stephenw10 I just tried it again and it works. Looks like they finally updated their certs. Thanks for the help!

@Rico sadly doesn't seem to solve the issue. I deployed the OpenVPN on ubuntu behind the firewall and forwarded the port, now I got it working. I am not sure why it's not working, to be honest, but the fact that it worked for a while and that its very slow without using any resources makes me believe something is unstable there, possibly with how my hosting solution manages VM's. Anyway thank you for all the help.

@PiBa Good news, I got it to work! I did as you suggested and got a self signed certificate on the server using this guide. After that HAProxy is able to route traffic to the host. It even works with the Let's Encrypt wildcard cert I have through the ACME package, so there's no cert errors getting to the site. Thank you for the help again.

@ddbnj said in Cannot access beyond router via OpenVPN: 10.8.0.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0 Yeah that would dick it up ;) Glad you got it sorted! Told you it wasn't pfsense ;) hehehehe The trick is getting the person to clearly see that themselves... Which is why the sniff proves to the user, hey pfsense is doing what its suppose to be doing... Have to look elsewhere..

@JKnott It is unusual, but it's the standard Comcast setup when you have a business account with static public IPs. For residential, or lower-tier business accounts, you get a dynamic public IP. I'm talking about v4, but they are now providing a static v6 block with the v4, and a residential user gets a dynamic /60.

No need tu put it off, because The style of routing described on that link won't work since pfSense doesn't enable the options for multiple routing tables So, what isn't implemented can't be switched off - neither on.

I realized that I do not need to add 192.168.0.x since my WAN interface is 192.168.0.1 and /32 was incorrect too. I have removed that. I can see the route in the table but still the ping to google.com or 8.8.8.8 or 192.168.0.1 from a VM(192.168.1.100) connected to pfsense is very random. how can I troubleshoot that? edit: do I have to reboot each time I save anything? that seems to do the trick

the routing table now is the same ? maybe it was something else on the configuration

So a smart/managed layer 2 then ;) BTW, if your going to route and your wanting to access something on your downstream from a IP that is on your transit network you are always going to run into asymmetrical problems.. If you want to route to other networks on your downstream, then that needs to be connected to your upstream router via a transit network.. If you going to want to get to it from devices on your transit network.. Then you need to host route on them, or you run into the above asymmetrical problem. Connect your upstream to your downstream via transit network (no hosts on it) and your asymmetrical issues are gone Also if you created your SVI on the L2 that your 10 network is on, then its IP would be in the 10 nework.. If you created put the svi on a different L2, then you need to route it via a transit or host routes or your going to have the asymmetrical problems.

Thanks for the book link. I'll have to take a look. Yeah, it seems just having a willingness to learn will get you a lot of the way there. I've done similar troubleshooting type things for friends who otherwise would've just accepted unstable internet service as normal. Their ISP usually tells them everything is fine so the ISP doesn't have to spend the resources to figure it out and some of them won't really do much until you beat them over the head with hard data that they can act on after you have basically done their job for them. And even then it can be like pulling teeth as you know. I'm basically tech support for all my friends and family. I'm sure you know the feeling. My experience has come from a lot of tinkering, breaking things, and attempting to fix them before someone yells at me for it.

Yeah you should be able to use either HAProxy or reverse Squid to redirect requests based on the host headers to different internal servers. Or different ports on the same server. https://docs.netgate.com/pfsense/en/latest/packages/haproxy-package.html Youtube Video Steve

Yeah Rico hit it on the head.. Where you can run into problems is when the site could be really any IP owned by the CDN its being hosted on.. So the specific IP you use could change all the time.. And some of these have ttls as short as 60 seconds for example... So when the filterdns process runs (every 5 minutes by default) that populates your alias for www.somedomain.com you get IP 1.2.3.4... But then 3 minutes your client wants to go there and you get 4.5.6.7 which is not in your alias. Even if you put in the whole swath of IPs that are owned by CDN.. you now get sites that you might not want going through the vpn since they are hosted on the same CDN, etc. So while yes you can do it.. Be aware that there could be complications based upon if that fqdn is hosted on CDN..

@jimp Thank you! Works perfectly as you described. Regards,

Sorry. I have no idea what you are even asking. The basic things that need to be changed to run pfSense HA in VMware ESXi are described here: https://docs.netgate.com/pfsense/en/latest/highavailability/troubleshooting-high-availability-clusters.html?highlight=esxi#hypervisor-users-especially-vmware-esx-esxi

How are the two networks connected now? You can't send traffic through a gateway in another subnet like that. You need some kind of transit network. For example, if it's a dedicated circuit, you'd have that plugged into an additional NIC (or VLAN) on both pfSense firewalls, and then you'd have some other unrelated subnet to talk between them there. Then you use the address in that subnet as a gateway to reach the other. If you have your LANs plugged together so they're all in the same Layer 2/flat network that is going to be a huge mess.

@ak-0 said in Internal routing of Vlans: @Derelict Vlan are created under physical Lan interface ig0 and parent interface for these vlan`s is ig0. Actually what i want to achieve is if traffic from Vlans goes out first it should reach Vlan gateway>>Lan gateway>> Wan port and should not do Vlan>>Wan port. Tracert should be 1.Vlan IP (192.168.100.1) 2.Lan IP (192.168.10.1) 3.Gateway IP (1.2.3.4) instead of 1.Vlan IP (192.168.100.1) 2.Gateway IP (1.2.3.4) I`m trying to double NAT for Vlans, first NAT should be internal and then gateway. @tim-mcmanus : If we simply capture the packet and on inspection it can show the source device and then the route the packet came from. So, someone with that much information and hacking knowledge can easily walk into your network. Also, can send packet with header upside down to hit the server behind pfsense firewall, located on VLAN. I've worked in environments that required double NATs, and I would suggest avoiding it at all costs. The only real reason to do this is IP overlap between networks. Security through obscurity is not something to rely on, and even if they knew your internal IP was 192.168.1.20, they can't do anything with it from the outside.

Using LAN is OK as long as you understand that you almost certainly shouldn't put anything but other routers with full infrastructure routing knowledge on LAN.

In the forums, similar cases of pfSense ignoring the static routes have been discussed in the past. In many cases, people mentioned using a floating rule to override this behaviour which did not work for me.

https://www.netgate.com/docs/pfsense/virtualization/virtio-driver-support.html

That'll do it!

2.3.2... I just don't get this.. Why would you not be on at least 2.3.5p2? 2.3.2 is no longer supported.. And to be honest the 2.3.x line is EOL here soon.. Like tmrw ;) https://www.netgate.com/blog/pfsense-release-2-3-x-eol-reminder.html

Yes. Just like you would with an rfc1918 network. If they routed 1.1.1.0/25 to you: Interface: 1.1.1.1 /25 Usable: 1.1.1.2 - 1.1.1.126 They'd set 1.1.1.1 as the gateway. Or you could configure DHCP to hand out the addresses if you wanted. You could also just use a /26, /27, /28, /29, /30, /31 on the inside interface and use the rest of the space for other purposes.

@rico I had a similar issue. Thanks for your advice!!

@grimm-spector Exactly, it will work just fine :)