VTI Palo --> Pfsense dynamic routing (OSPF)

heinola

IPSEC_VTI:
broadcast
Ignore MTU

Sending 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 44

Firewall rule Pfsense:
Ipsec --> allow any TCP any PROT from any

heinola

@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

heinola

@heinola

Getting closer but in INIT state:

OSPF Neighbors
/usr/local/lib/libfrr.so.0: Unable to relocate undefined weak TLS variable

Neighbor 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

michmoor

@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 any

OSPF doesn’t use TCP.

heinola

@michmoor

sry I ment this:

One the PA the tunnel interface is in the trusted zone

michmoor

@heinola you didn’t tell me what the firewall logs look like on the PA. Every zone needs firewall rules

heinola

@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.

michmoor

@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

@michmoor

**Figured it out:

It didn't like the multicast so much. So i did the P2P**

michmoor

@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.

heinola

@michmoor

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

heinola

@heinola

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