Time is not syncing



  • @brunovic said in Time is not syncing:

    @beremonavabi ah no I am not using the client on my pfsense just the server.

    Well, an OpenVPN server commonality might be a start. Mine is listening on port 443. My firewall rules on the WAN look like:

    0_1528994663634_20180604 -- Firewall Rules WAN.PNG

    Like you, my NAT rules are Manual. Outside of your specific ports, mine look similar:

    0_1528994721603_20180610 -- pfSense Firewall NAT Outbound.PNG

    For DNS, I’m using DNS Resolver in NON-Forwarding mode. It’s active for all my local LAN-type interfaces (not WAN). Though, since I've checked with NTP using actual IP addresses instead of pool names (as you did), I can't see how this could be DNS related.


  • LAYER 8 Global Moderator

    @beremonavabi said in Time is not syncing:

    NTP will ONLY run on my SG-4860 if WAN is selected to listen

    I have sg4860, I run both vpn servers on multiple instances 443 tcp, 1194 udp and also a vpn client connection to a vps out on the net running openvpn-as..

    But I am NOT pulling routes from that connection and only policy route out to that vpn if need a client to take that path.. And I am NOT listening on the wan port and have zero issues with ntp talking to outbound ntp per previous screen shots.

    So you clearly have something messed up in your configuration causing this problem there is zero reason that ntp should have to listen on wan to talk to ntp servers on the internet.



  • @johnpoz said in Time is not syncing:

    @beremonavabi said in Time is not syncing:

    NTP will ONLY run on my SG-4860 if WAN is selected to listen

    I have sg4860, I run both vpn servers on multiple instances 443 tcp, 1194 udp and also a vpn client connection to a vps out on the net running openvpn-as..

    But I am NOT pulling routes from that connection and only policy route out to that vpn if need a client to take that path.. And I am NOT listening on the wan port and have zero issues with ntp talking to outbound ntp per previous screen shots.

    So you clearly have something messed up in your configuration causing this problem there is zero reason that ntp should have to listen on wan to talk to ntp servers on the internet.

    I'm also not pulling routes. I'm mostly clueless about this, but my routes look fine, to me:

    IPv4 Routes
    Destination	Gateway	Flags	Use	Mtu	Netif	Expire
    0.0.0.0/1	10.4.0.1	UGS	16952	1500	ovpnc1	
    default		[my WAN IP]	UGS	34	1500	igb1	
    10.4.0.0/16	10.4.0.1	UGS	0	1500	ovpnc1	
    10.4.0.1	link#12	UH	371622	1500	ovpnc1	
    10.4.0.14	link#12	UHS	0	16384	lo0	
    10.8.0.0/16	10.8.0.1	UGS	0	1500	ovpnc2	
    10.8.0.1	link#13	UH	371535	1500	ovpnc2	
    10.8.0.27	link#13	UHS	0	16384	lo0	
    [my WAN net]/24	link#2	U	371654	1500	igb1	
    [my WAN IP]	link#2	UHS	0	16384	lo0	
    127.0.0.1	link#7	UH	6821	16384	lo0	
    128.0.0.0/1	10.4.0.1	UGS	84534	1500	ovpnc1	
    192.168.1.0/24	link#1	U	0	1500	igb0	
    192.168.1.1	link#1	UHS	0	16384	lo0	
    192.168.10.0/24	link#3	U	0	1500	igb2	
    192.168.10.1	link#3	UHS	0	16384	lo0	
    192.168.20.0/24	link#4	U	10946342	1500	igb3	
    192.168.20.1	link#4	UHS	0	16384	lo0	
    192.168.30.0/24	link#5	U	464495	1500	igb4	
    192.168.30.1	link#5	UHS	0	16384	lo0	
    192.168.40.0/24	link#6	U	0	1500	igb5	
    192.168.40.1	link#6	UHS	0	16384	lo0	
    192.168.200.0/24	192.168.200.2	UGS	333989	1500	ovpns3	
    192.168.200.1	link#11	UHS	743340	16384	lo0	
    192.168.200.2	link#11	UH	33730	1500	ovpns3	
    [VPN address]/32	[my WAN IP]	UGS	456678	1500	igb1	
    [VPN address]/32	[my WAN IP]	UGS	5024988	1500	igb1	
    
    

    EDIT: Since only a handful of us have had this issue, I agree that I must have something messed up in my configuration. But I have no idea what it is. And, since nothing in my logs leaps out at me as being a problem, I don't even know where to look. I've pretty much given up on this and am just living with NTP on WAN.


  • LAYER 8 Global Moderator

    @beremonavabi said in Time is not syncing:

    0.0.0.0/1 10.4.0.1 UGS 16952 1500 ovpnc1

    No your pulling routes if you have something like that..

    You blocked routes from your client config? See how have only my wan default route and only routes for my client connection are the network its connected too.0_1529004862429_notpull.png



  • @johnpoz I've got the same "Don't pull routes" box checked in my VPN clients. The 0.0.0.0/1 (and the 128.0.0.0/1) routes are added with the "redirect-gateway def1" Custom Option I'm using. That redirects all my traffic through the VPN (whereas you are policy routing specific clients), but leaves the default route untouched so the firewall, itself, can get through the WAN:

    https://forum.netgate.com/topic/115760/firewall-traffic-needs-redirect-gateway-def1-to-route-thru-vpn

    That being said, I had also been wondering if that could be causing the issue. But, since the OP of this thread isn't using a VPN client on pfSense, he shouldn't have those routes set. So, if that were the problem, he shouldn't be seeing it. Also, from my other thread I referenced earlier, I'm pretty sure that's what I tried to work around with a specific Outgoing NAT rule to allow UDP 123 traffic to go through the WAN:

    0_1529006304514_20180610 -- pfSense NTP Fix Question.PNG

    That didn't work. So, obviously it didn't do what I thought it might.

    Still, that's all on the routing side. I still don't understand why having NTP listen on the WAN would allow this to work. AFAIK, the NTP client on pfSense sends out traffic asking for the time and gets a response. There shouldn't be anything legitimate arriving unsolicited from the internet. So, the incoming NTP traffic ought to get right through the firewall since it's in response to a legitimate request.

    Do you have any blocking rules on your WAN to block incoming private/bogon networks? Or, do you just let the default "block everything" behavior in pfSense handle that? Could the NTP traffic from my setup be somehow avoiding NAT, going out with my private address on it, and getting blocked on the way back in by my rules?


  • LAYER 8 Global Moderator

    @beremonavabi said in Time is not syncing:

    Custom Option I’m using.

    Same problem then... Why would you be doing that.. Turn that off - does your ntp start working now... Its quite possible your vpn is just blocking ntp. Sniff on your vpn interface do you see the ntp queries go out?

    Argghhh I wish people would stop jumping into threads that have NOTHING to do with their problem or their setup is completely different..



  • @johnpoz said in Time is not syncing:

    Argghhh I wish people would stop jumping into threads that have NOTHING to do with their problem or their setup is completely different..

    What are you talking about? I "jumped" into this thread and gave the OP the solution he needed to get NTP working (select the WAN in Services > NTP). I then noted he was using VPN, as was I. That's a point in common. I was trying to explore that as possibly relating to this issue. In what way did I jump in with something not related to the problem?

    But, I guess, just forget it.


  • LAYER 8 Global Moderator

    @beremonavabi said in Time is not syncing:

    (select the WAN in Services > NTP)

    That is NOT a solution... That is a work around for some other misconfig..

    Did you do what I suggested and remove the 0.0.0.0 route you have and see if works then not picking wan.



  • So to follow up on my issue which may be different from beremonavabi's. When I have the NTP interfaces set to internal interfaces I am unable to sync with NTP servers however when I ping I can get to them just fine. But when I selected WAN interface for NTP I am able to sync with the NTP servers. What could be causing that?



  • Also under NTP what does selecting those interfaces even mean? How does it "listen" on those interfaces for NTP? Does it just mean that it sources the interface IPs? That part right there really confuses me.



  • NTP is 100% UDP and with UDP your application (in this case the NTP service) is responsible for both sending out the queries and listening for replies. This is completely unlike compared to TCP where TCP does all the heavy lifting for you with setting up the connection and dealing with the return traffic. The consquence of this is that any application using a UDP based protocol has to listen on a socket to do anything, even if it's just a client querying other servers.



  • This post is deleted!


  • @kpa said in Time is not syncing:

    NTP is 100% UDP and with UDP your application (in this case the NTP service) is responsible for both sending out the queries and listening for replies. This is completely unlike compared to TCP where TCP does all the heavy lifting for you with setting up the connection and dealing with the return traffic. The consquence of this is that any application using a UDP based protocol has to listen on a socket to do anything, even if it's just a client querying other servers.

    Okay. That doesn't answer my question though. My questions are:

    1. Why does it sync on WAN but not on any of the internal interfaces
    2. What does it mean by it is "listening" on those interfaces. I need to know from a routing perspective. I've done a ping sourcing those interfaces and pings from LAN, GUEST, etc come back with 0% packet loss. So if what you are telling me is true IF NTP is listening on though interfaces then UDP should not have a problem IF ICMP is fine.


    1. Post your outbound NAT configuration, if WAN is deselected from the interfaces the NTP service might be trying to bind to another interface but the outgoing connections fail because of faulty outbound NAT settings.

    2. It means literally what it says, listening for incoming data packets on the said interface. UDP is connectionless and stateless, an application that uses the UDP socket sends out a data packet (or multiples depending on the protocol) and then stops in listening mode to wait for the replies to the sent packets. Once those are received the data is processed and the loop starts again by either sending out more data or staying in listening mode for more incoming packets.



  • @brunovic said in Time is not syncing:

    @johnpoz so it looks like my outbound NAT is manually configured. How will this prevent NTP from syncing?

    0_1528993260522_Capture08.JPG

    This is what you are looking for right?



  • @kpa if that is the case then why would it be listening to NTP packets on the LAN and not the WAN? That server is not on my internal network.



  • @brunovic

    Your router can provide ntp to clients on your lan, that’s why it listens on the lan interface.

    Have a look at the dhcp settings for your lan subnet.


  • LAYER 8 Global Moderator

    Why do you have it in manual mode if all you doing is what automatic would be doing?

    Where is your nat for vpn connections, your tunnel network would need to be natted? Try changing it to automatic.. You sure and the hell should not have to listen on wan to query a time server.



  • @johnpoz said in Time is not syncing:

    Why do you have it in manual mode if all you doing is what automatic would be doing?

    Where is your nat for vpn connections, your tunnel network would need to be natted? Try changing it to automatic.. You sure and the hell should not have to listen on wan to query a time server.

    There is a reason to it. I can't remember but something was not working correctly in automatic mode.


  • LAYER 8 Global Moderator

    Like what? Put it back.. And delete all your manual rules. You can always put it back to manual if this whatever it is comes back.. But if there is something that is not working in automatic mode that should be brought up so we can fix it, so other users using automatic don't have whatever this is issue is you think you were having.


  • Rebel Alliance Developer Netgate

    @brunovic said in Time is not syncing:

    There is a reason to it. I can't remember but something was not working correctly in automatic mode.

    This makes me think you have some other misconfiguration as the root cause here. If your WAN is static, make sure you have a gateway set on Interfaces > WAN. And also check Interfaces > LAN and make sure you do not have a gateway set there. Same for your other local interface(s) like Guest.



  • @jimp said in Time is not syncing:

    @brunovic said in Time is not syncing:

    There is a reason to it. I can't remember but something was not working correctly in automatic mode.

    This makes me think you have some other misconfiguration as the root cause here. If your WAN is static, make sure you have a gateway set on Interfaces > WAN. And also check Interfaces > LAN and make sure you do not have a gateway set there. Same for your other local interface(s) like Guest.

    If you see my route print screen above the only quad zeros out are on the WAN interface.



  • @johnpoz said in Time is not syncing:

    Like what? Put it back.. And delete all your manual rules. You can always put it back to manual if this whatever it is comes back.. But if there is something that is not working in automatic mode that should be brought up so we can fix it, so other users using automatic don't have whatever this is issue is you think you were having.

    I'll keep it at manual. I am VPN into my network. If these manual routes were for that the last thing I want to to hose my own connection. All I need to know is what outbound NAT rule should I be seeing in order for NTP to work without having to select the WAN interface.


  • Rebel Alliance Developer Netgate

    @brunovic said in Time is not syncing:

    If you see my route print screen above the only quad zeros out are on the WAN interface.

    That has nothing at all to do with what I said or why I asked. :-)

    Read my message again and check the settings I mentioned.



  • @jimp said in Time is not syncing:

    @brunovic said in Time is not syncing:

    If you see my route print screen above the only quad zeros out are on the WAN interface.

    That has nothing at all to do with what I said or why I asked. :-)

    Read my message again and check the settings I mentioned.

    What does the gateway setting do?


  • Rebel Alliance Developer Netgate

    @brunovic said in Time is not syncing:

    What does the gateway setting do?

    It controls whether or not pfSense treats an interface like a "WAN" for NAT and other purposes. If you have no gateway on WAN, or a gateway set on LAN or other internal interfaces, it will confuse the code that tries to setup automatic NAT and other functions.

    WANs must have a gateway selected in their interface settings (statics anyhow, dynamics will get this automatically), LANs must not have a gateway set on the interface settings.



  • Also if it helps one of the things I had to do was create rules that seperated VLAN traffic from one another. This is a bit reverse from Cisco where you have to assign VTI and create route statements before any VLAN can start talking with one another. However for pfsense the moment you create a VLAN everything is automatically routed between VLANs. I do not like that at all. All I want are the VLANs to be independant from each other and for them to get out to the internet on their own. If I want to route traffic between VLANs I should be able to opt-in not opt-out. As a result I ended making some janky solution where I created alias with all other VLAN networks but it's own and told it to go anywhere but those networks.

    0_1529510532465_Capture09.JPG
    0_1529510540718_Capture10.JPG


  • Rebel Alliance Developer Netgate

    @brunovic said in Time is not syncing:

    Also if it helps one of the things I had to do was create rules that seperated VLAN traffic from one another. This is a bit reverse from Cisco where you have to assign VTI and create route statements before any VLAN can start talking with one another. However for pfsense the moment you create a VLAN everything is automatically routed between VLANs. I do not like that at all. All I want are the VLANs to be independant from each other and for them to get out to the internet on their own. If I want to route traffic between VLANs I should be able to opt-in not opt-out. As a result I ended making some janky solution where I created alias with all other VLAN networks but it's own and told it to go anywhere but those networks.

    Routing happens automatically, rules do not. They were allowed to do that because your rules allowed it. If you setup your rules properly, that won't happen. That's not related to this thread, however.



  • @jimp said in Time is not syncing:

    @brunovic said in Time is not syncing:

    What does the gateway setting do?

    It controls whether or not pfSense treats an interface like a "WAN" for NAT and other purposes. If you have no gateway on WAN, or a gateway set on LAN or other internal interfaces, it will confuse the code that tries to setup automatic NAT and other functions.

    WANs must have a gateway selected in their interface settings (statics anyhow, dynamics will get this automatically), LANs must not have a gateway set on the interface settings.

    Anyways to answer your question there is no setting under the WAN interface to designate it as the gateway. And all other interface are not designated the gateway.



  • I feel like no one is talking to me like a network engineer. I never had this much difficulty trying to configure a Cisco router, firewall or switch. I may have screwed something up and I think the problem here is you guys are trying to troubleshoot my problem. I am pretty proficient enough to troubleshoot it myself. But the one answer I have not been getting it HOW exactly is the NTP communication routing? Is the NTP server sourcing the LAN interface going out the WAN or is it sending the NTP out the LAN interface. That is what is confusing me about the "interface section" under NTP Server Settings. If it is the latter then no wonder it isn't syncing because there are no NTP servers on my LAN network however IF it is the former. I have already done a ping test to the NTP server SOURCING the LAN interfaces and I got 100% replies. IF this is a NAT issued then pings would fail.


  • Rebel Alliance Developer Netgate

    @brunovic said in Time is not syncing:

    I feel like no one is talking to me like a network engineer. I never had this much difficulty trying to configure a Cisco router, firewall or switch. I may have screwed something up and I think the problem here is you guys are trying to troubleshoot my problem.

    This isn't Cisco. And if you don't want help, I'll gladly not give it. You have precisely the kind of attitude found on a person most likely to overlook something because they think they know better, and that is why it's most important to start with the basics and work up.

    NTP is UDP. UDP will follow the routing table. The interface binding controls what it binds to locally, but it still respects the routing table to find the interface it will exit from. If you bind to LAN, it will source the packets using the LAN IP address but the traffic still exits the firewall through whatever route gets it to the destination (e.g. the default route). Sourcing from the LAN and exiting WAN also means that it gets NAT applied.

    On my test systems here, I can select LAN only and it still can synchronize time just fine, with otherwise stock NTP settings.



  • @jimp said in Time is not syncing:

    @brunovic said in Time is not syncing:

    I feel like no one is talking to me like a network engineer. I never had this much difficulty trying to configure a Cisco router, firewall or switch. I may have screwed something up and I think the problem here is you guys are trying to troubleshoot my problem.

    This isn't Cisco. And if you don't want help, I'll gladly not give it. You have precisely the kind of attitude found on a person most likely to overlook something because they think they know better, and that is why it's most important to start with the basics and work up.

    NTP is UDP. UDP will follow the routing table. The interface binding controls what it binds to locally, but it still respects the routing table to find the interface it will exit from. If you bind to LAN, it will source the packets using the LAN IP address but the traffic still exits the firewall through whatever route gets it to the destination (e.g. the default route). Sourcing from the LAN and exiting WAN also means that it gets NAT applied.

    On my test systems here, I can select LAN only and it still can synchronize time just fine, with otherwise stock NTP settings.

    I understand this is not Cisco. What I am trying to do is to get you to understand that I understand the networking basics and from a network standpoint everything looks good. Now unless there is something that has been done without my knowledge THAT is what I need to know. But I would not set the internal interfaces to be the gateway because I know that will break network traffic. I've already confirmed this with you when I checked the LAN interface. Also IF this is a NAT issue the whole point of Network Address Translation is for internal class c addresses to source the WAN interface IP for external traffic. As I've demonstrated when sourcing the LAN interface IP I am able to ping the NTP server. If NAT was not working properly I should not be able to ping the NTP server from the LAN interface. So this leaves the question IF NAT is working properly and I am able to ping the NTP servers then WHY am I not able to sync with the NTP server when anything but the WAN interface is selected under the NTP Settings.

    0_1529512971315_Capture11.JPG



  • Boom THAT was why I had the manual NAT. Now my out-of-band management VLAN can get onto the internet and this violates DoD STIG requirements. THAT was why I was trying to keep the manual NAT. Again everything routes by default which creates THAT problem. I just need that network to be on its own separate from the rest of the networks. There are no rules on the ADMIN VLAN to allow anything so why am I able to route on the ADMIN VLAN. That was what I didn't want to do.


  • Rebel Alliance Developer Netgate

    @brunovic said in Time is not syncing:

    Boom THAT was why I had the manual NAT. Now my out-of-band management VLAN can get onto the internet and this violates DoD STIG requirements. THAT was why I was trying to keep the manual NAT. Again everything routes by default which creates THAT problem. I just need that network to be on its own separate from the rest of the networks. There are no rules on the ADMIN VLAN to allow anything so why am I able to route on the ADMIN VLAN. That was what I didn't want to do.

    Because interface rules are checked in the inbound direction, not outbound. Through your lack of understanding of how pfSense works, you created the misconfiguration that allowed it to happen. You keep shooting your own feet and then wondering why it hurts.

    You need to read through the docs more and understand how pfSense operates at a more fundamental level before ranting about how it doesn't work the way you expect. You're still applying Cisco concepts to pfSense when they do not apply at all.



  • WITH Auto NAT:
    0_1529514648362_Capture12.JPG

    WITHOUT Auto NAT (Manual excluding the ADMIN network):
    0_1529514697871_Capture13.JPG

    The second one is what I need to happen. There are no rules on the ADMIN VLAN however it is still able to route out.



  • YOU GOT TO BE KIDDING! The simple answer was to NOT select the ADMIN interface under NTP settings! I didn't even select it but when I remembered why I did manual NAT I had a hunch that that was the problem. BECAUSE traffic cannot route out the ADMIN interface NTP failed! That makes absolutely NO sense!



  • As you can see I've fixed it myself without your help. Instead of helping me you kept troubleshooting things that did not need troubleshooting. You kept arguing with me and would not listen to a word I said. I have said REPEATEDLY that NAT is not the problem because I was able to ping sourcing the LAN interface. You kept insisting it was the problem. I kept asking you HOW exactly the NTP client was reaching the NTP server. The best answer I got was that it was "listening" on those interfaces. That really does not help me out. If that is the case even IF the ADMIN interface which does not have a NAT rule was selected so was LAN and GUEST. So it should still have been able to reach the NTP server on those interfaces. I still do not understand WHY I need to remove the ADMIN interface in order for it to work and I doubt I will get a straight answer from you. But I needed to remove the ADMIN network from NAT because it was automatically routing traffic. This is why I brought up Cisco. NOT to show off but to give you a reference point of where I stand from a Network Engineer perspective. By default there are no routes when VTIs are created. That is what I was expecting from pfSense. Yes I know pfSense is NOT a Cisco device but I need THAT function to act like Cisco. Cisco has designed VLANs to be independent network FOR security reasons. To have automatic routing is a security vulnerability and I need for that to not happen. The ONLY work around I could find was to remove the NAT and make exclusion rule to segment off networks.

    With ADMIN selected and Manual NAT:
    0_1529515701274_Capture14.JPG
    0_1529515714476_Capture15.JPG

    Without ADMIN selected and Manual NAT:
    0_1529515743202_Capture16.JPG
    0_1529515752506_Capture17.JPG


  • LAYER 8 Global Moderator

    Good for you ;)

    I am glad it got sorted, for sure gives me more things to ask the next user on stuff they could of dicked up.

    I agree with jimp here - you shot yourself in the foot.. You should of mentioned out of the gate that you were not using a default gateway and not using automatic nat, etc.

    Unless the user mentions it, you have to assume pfsense is in a default configuration mode.. So normally these threads come down to pulling the info out of the user and trying to figure out what thing did they dick with or multiple things to break it..



  • This is BS: https://youtu.be/FlVjrB4SByQ?t=2m18s

    You are saying there is an implicit deny in this video. That said if there are no rules then I should NOT be able to route between VLANs. Is that my "lack of understanding" you are referring to? If that is the case with no rules on the ADMIN interface I should not have been able to ping out on the WAN much less any other local network. Let me show you something. I will add the auto NAT rules back in and remove ALL rule on the ADMIN network and show you that I am still able to ping out and internally. IF there is an implicit deny statement then I should not be able to do this right? Then why am I able to do this? Please don't come at me with that "lack of understanding" crap. Your own documentation and video contradict the results. What I do understand is what is happening on my pfSense. If rules are supposed to allow traffic then why is it when I have no rules traffic is still allowed. THAT is why I had to manually configure my NAT!

    0_1529518458853_Capture18.JPG
    0_1529518476778_Capture19.JPG
    0_1529518485655_Capture20.JPG
    0_1529518495209_Capture21.JPG


  • Rebel Alliance Developer Netgate

    As you can see I’ve fixed it myself without your help.

    Good for you.

    Instead of helping me you kept troubleshooting things that did not need troubleshooting. You kept arguing with me and would not listen to a word I said.

    Except that I did, and you assumed you were right and I was wrong and missed the point completely.

    I have said REPEATEDLY that NAT is not the problem because I was able to ping sourcing the LAN interface. You kept insisting it was the problem.

    Except NAT was the problem. See below.

    I kept asking you HOW exactly the NTP client was reaching the NTP server. The best answer I got was that it was “listening” on those interfaces. That really does not help me out.

    Except that it was the most correct answer to what you asked with the information you provided. You did not show your NTP settings anywhere. You did not mention any "admin" interface being selected in NTP, only LAN.

    If that is the case even IF the ADMIN interface which does not have a NAT rule was selected so was LAN and GUEST.

    The lack of NAT for admin was the problem because it chose the Admin interface as the source. With multiple interfaces selected the OS picks whichever interface is "closest" to the targets, for whatever reason, Admin came up first in that decision making process.

    So it should still have been able to reach the NTP server on those interfaces.

    Except that it didn't, the NTP daemon picked the Admin interface for whatever reason, and NTP apparently doesn't try other addresses automatically.

    I still do not understand WHY I need to remove the ADMIN interface in order for it to work and I doubt I will get a straight answer from you.

    Because ADMIN has no outbound NAT, and NTP is trying to communicate with the outside world using the Admin interface IP address.

    But I needed to remove the ADMIN network from NAT because it was automatically routing traffic.

    Wrong. Taking it out of NAT does not prevent it from routing. The traffic still exits WAN, just without NAT. You need proper firewall rules.

    This is why I brought up Cisco. NOT to show off but to give you a reference point of where I stand from a Network Engineer perspective.

    But as you have shown, that experience means little to anything other than Cisco.

    By default there are no routes when VTIs are created. That is what I was expecting from pfSense.

    By default in pfSense there are no rules when interfaces are created.

    Yes I know pfSense is NOT a Cisco device but I need THAT function to act like Cisco. Cisco has designed VLANs to be independent network FOR security reasons. To have automatic routing is a security vulnerability and I need for that to not happen. The ONLY work around I could find was to remove the NAT and make exclusion rule to segment off networks.

    Again, it works this way by default if you create a proper set of firewall rules. It isn't a security vulnerability, it's mismanagement by the admin.


Log in to reply