VTI Palo --> Pfsense dynamic routing (OSPF)
-
well lets start with basics. Is OSPF enabled on the VTI interfaces and not set to passive?
Have you done a packet capture and can you see OSPF hello packets going transmitted or received?
I currently am doing BGP across a site and although not the same , protocol speaking, dynamic routing does work. The other end is a Cisco appliance. -
IPSEC_VTI:
broadcast
Ignore MTUSending OSPF (is this sending & receiving?) :
05:24:45.597232 IP 172.27.67.250 > 224.0.0.5: OSPFv2, Hello, length 44
05:24:45.597514 IP 172.27.67.249 > 224.0.0.5: OSPFv2, Hello, length 44
05:24:55.597913 IP 172.27.67.250 > 224.0.0.5: OSPFv2, Hello, length 44
05:24:55.598318 IP 172.27.67.249 > 224.0.0.5: OSPFv2, Hello, length 44
05:25:05.598269 IP 172.27.67.250 > 224.0.0.5: OSPFv2, Hello, length 44
05:25:05.598738 IP 172.27.67.249 > 224.0.0.5: OSPFv2, Hello, length 44Firewall rule Pfsense:
Ipsec --> allow any TCP any PROT from any -
@heinola
The Palo might be blocking it somewhere:05:57:44.090924 IP 172.27.67.249 > 172.27.67.250: ICMP echo request, id 61461, seq 1829, length 9
05:57:44.599679 IP 172.27.67.249 > 172.27.67.250: ICMP echo request, id 61461, seq 1830, length 9
05:57:45.131932 IP 172.27.67.249 > 172.27.67.250: ICMP echo request, id 61461, seq 1831, length 9
05:57:45.664170 IP 172.27.67.249 > 172.27.67.250: ICMP echo request, id 61461, seq 1832, length 9
05:57:45.671085 IP 172.27.67.250 > 224.0.0.5: OSPFv2, Hello, length 44
05:57:46.186924 IP 172.27.67.249 > 172.27.67.250: ICMP echo request, id 61461, seq 1833, length 9
05:57:46.719164 IP 172.27.67.249 > 172.27.67.250: ICMP echo request, id 61461, seq 1834, length 9
05:57:47.246912 IP 172.27.67.249 > 172.27.67.250: ICMP echo request, id 61461, seq 1835, length 9
05:57:47.763203 IP 172.27.67.249 > 172.27.67.250: ICMP echo request, id 61461, seq 1836, length 9
05:57:47.919920 IP 172.27.67.249 > 224.0.0.5: OSPFv2, Hello, length 44
05:57:48.274724 IP 172.27.67.249 > 172.27.67.250: ICMP echo request, id 61461, seq 1837, length 9
05:57:48.798857 IP 172.27.67.249 > 172.27.67.250: ICMP echo request, id 61461, seq 1838, length 9 -
Getting closer but in INIT state:
OSPF Neighbors
/usr/local/lib/libfrr.so.0: Unable to relocate undefined weak TLS variableNeighbor ID Pri State Dead Time Address Interface RXmtL RqstL DBsmL
192.168.20.2 1 Init/DROther 38.764s 172.27.67.250 ipsec1:172.27.67.249 0 0 0 -
@heinola check the Palo Logs
Monitor - Traffic.
Should be rather easy to see if the packets are coming in.Also I’m assuming you have open rules on each side for testing? Permit any any?
Not understanding this rule.
Ipsec --> allow any TCP any PROT from anyOSPF doesn’t use TCP.
-
-
@heinola you didn’t tell me what the firewall logs look like on the PA. Every zone needs firewall rules
-
@michmoor
Made Palo side of VTI IP able to be pinged but not visa versa: VTI Gateway status is good
I see the neighbor has been seen but not fully:
Only traffic I see on that Palo is the gateway ping alive gateway from the Pfsense:
Palo tunnel interface is part of trusted zone that uses intrazone default rule only. ( this is what the other Palo's are using for there ipsec VPN's as well. So it has to be something with ospf not fully forming to add routed needed on both side. But it is getting closer. I will keep playing around with it.
-
@heinola I’m pretty sure the problem is on the PA side as you are seeing the Init state which means you are receiving hello packets/
As you haven’t shown your traffic logs on the PA I can assume you don’t have access to that firewall. Have who ever manages it see if drops are being seen. You need a rule for this. -
-
@heinola glad it's resolved. The explantation by Palo about what P2P does is a bit confusing
p2p automatically discovers neighbors but it doesnt state how...i would assume multicast as thats done on Cisco or Arista
But Broadcast also automatically discovers neighbors but it states through multicast.
So whats the difference?
The only option there that would make sense is p2mp where you use Unicast but thats not what you selected.
-
You got me there.. it should of worked the other way that is was.
It has to be something with the numbered tunnel interface and how it Nat's maybe?
remote subnet >> PF virtual tunnel ip >> tunnel ------- tunnel >> pa virtual tunnel ip >> local subnet.
Looks like all our tunnels are part of the trusted zone ( same as internal network). No rules applied here would work.
Has to be NAT PAT thing on the virtual tunnel ip thats all i got..
Hope this help someone else out a bit ty michmoor
-
Think its like:
broadcast = hey everyone ( please sir can i have some more )
p2p = hey you xxx.xxx.xxx.xxx ( give me what i want )or am i way way off
