2026-10-26T18:25:57Z https://nostr.now EmZaid 🫥 https://nostr.now/npub1vk8lr3te0jmmup6n0ugw9vl0ay6mfc25z947gwn7ak40ux3m428sahjy73 https://media.infosec.exchange/infosec.exchange/accounts/avatars/109/309/652/832/266/382/original/eeda1f378900097c.png https://media.infosec.exchange/infosec.exchange/accounts/avatars/109/309/652/832/266/382/original/eeda1f378900097c.png https://nostr.now/nevent1qqs96rxx0vydup56jz4pks4ekxaa3ehxcmc6p0gees803xhdzekyvxczypjcluw9097t00s82dl3pc4nal5ntd8p2sgkhep60mk64ls68w4g7l7zce8 In reply to <a href='/nevent1qqszzjwmlkhsezxuec8fm83dsqny2jdk7evtuv8wqkc8nckg0es57ms7xdn9f'>nevent1q…dn9f</a><br/>_________________________<br/><br/>perfect. I don&#39;t have a good sense of what is normal fw stuff since this current place is the only place I&#39;ve done this work 🙃 2026-10-26T20:23:00Z https://nostr.now/nevent1qqsxjkj0uuzcn5sr2pxxfhqr7wy58tx3rf4k7cajwlhdecxymkqpmnczypjcluw9097t00s82dl3pc4nal5ntd8p2sgkhep60mk64ls68w4g7cdltvw In reply to <a href='/nevent1qqs97aju7qld8ullxs5qxhrhm9anxuzvr2tfe79q9w28erkxs2wnd4cz9cmju'>nevent1q…cmju</a><br/>_________________________<br/><br/>I don&#39;t manage them which makes me happy given their recent spat of cves lol 2026-10-26T20:17:07Z https://nostr.now/nevent1qqsr0askaggq9wmy3vc2vacs5wn93z5dlpy3cz4cz8yjm3539qzdqhczypjcluw9097t00s82dl3pc4nal5ntd8p2sgkhep60mk64ls68w4g7qglakh In reply to <a href='/nevent1qqsvx9fv0eszlzzzjrnl3emfff8cuvepttxpmfllm2hnh2kzhnqa2nszz3atm'>nevent1q…3atm</a><br/>_________________________<br/><br/>let&#39;s say we have 30ish routing instances that may or may not need to be extended to 30ish remote sites. currently that is done via mpls. (or one gre tunnel per instances...)<br/><br/>I&#39;m proposing doing a split tunnel at the remote side, an ipsec tunnel back to central, and doing pbf on the same vsys where the ipsec tunnels land. it would require one pbf rule per routing instance we want to extend (and each instance gets its own /16 to keep the rules simple). the goal is that new remote site deployments only require one ipsec tunnel, one bgp peer, and then layer3 interfaces for any routing instances required. I want this dead simple for folks to deploy. 2026-10-26T18:27:28Z https://nostr.now/nevent1qqstsfenkye3xzwvk4xd9a7gc3w6vvm0auflwpczsh7ngt8eh5s85jszypjcluw9097t00s82dl3pc4nal5ntd8p2sgkhep60mk64ls68w4g7plk6h5 In reply to <a href='/nevent1qqst8mkn4myuu7az6qq8pqcmc835j85hrde8lmevzfnf9pkus3zjzhgzujr30'>nevent1q…jr30</a><br/>_________________________<br/><br/>the mtu issue is/was related to the juniper srx (mpls CE) being weird with mtu. we have tried a bunch of things (and are about to attempt mss clamping). We had some success with changing the srx mode but the details allude me right now. <br/><br/>The assumption I&#39;m making is that ipsec (and by extension a palo on both ends) will handle mtu discovery better than gre. <br/><br/>I&#39;m glad to hear that pbf can be a solid choice 2026-10-26T18:18:22Z https://nostr.now/nevent1qqs0z39cyaekh2yf9xucpaget26a0qqeuxju392d69m46r8qkdy4cyczypjcluw9097t00s82dl3pc4nal5ntd8p2sgkhep60mk64ls68w4g7nphtpf ok networking folks. how scared should I be of using policy based forwarding? palo seems to be discouraging it heavily (in favor of prisma), but I&#39;m under the assumption that if I scope it right (large IP blocks with simple pbf policies) pbf shouldn&#39;t be thattt bad? <br/><br/>Palo seemed to imply pbf shouldn&#39;t be used for any greenfield deployment?<br/><br/>(for context I&#39;m building a custom sd-wan solution to replace mpls over gre due to unsolved mtu issues lol) 2026-10-26T17:57:25Z