About bdunbar

That did it, thank you very much. ... View more

"Can you ping default gateway" Nope. admin@tn-gateway-01> ping host 10.220.0.1 PING 10.220.0.1 (10.220.0.1) 56(84) bytes of data. From 10.220.0.127 icmp_seq=3 Destination Host Unreachable From 10.220.0.127 icmp_seq=4 Destination Host Unreachable From 10.220.0.127 icmp_seq=5 Destination Host Unreachable From 10.220.0.127 icmp_seq=6 Destination Host Unreachable ^C --- 10.220.0.1 ping statistics --- 7 packets transmitted, 0 received, +4 errors, 100% packet loss, time 6023ms , pipe 3 "or does firewall learn ARP entry for default gateway." You lost me.  Sorry: I don't know where to find a value like that?  If it helps .. my arp table .. admin@tn-gateway-01> show arp all maximum of entries supported :      500 default timeout:                    1800 seconds total ARP entries in table :        14 total ARP entries shown :           14 status: s - static, c - complete, e - expiring, i - incomplete interface         ip address      hw address        port              status   ttl -------------------------------------------------------------------------------- ethernet1/4       209.59.29.194   00:25:90:d1:e9:36 ethernet1/4         c      315 ethernet1/4       209.59.29.195   00:25:90:af:44:44 ethernet1/4         c      744 ethernet1/4       209.59.29.196   00:25:90:d1:ea:88 ethernet1/4         c      999 ethernet1/4       209.59.29.199   00:25:90:d1:e9:07 ethernet1/4         c      756 ethernet1/4       209.59.29.201   a0:36:9f:1d:fe:8c ethernet1/4         c      849 ethernet1/4       209.59.29.203   00:0c:29:f7:8b:ba ethernet1/4         c      547 ethernet1/4       209.59.29.210   a0:36:9f:21:96:f0 ethernet1/4         c      1722 ethernet1/4       209.59.29.221   00:0c:29:ab:17:b0 ethernet1/4         c      1788 ethernet1/4       209.59.29.222   00:0c:29:75:a7:f9 ethernet1/4         c      1423 ethernet1/4       209.59.29.224   00:0c:29:ff:4f:54 ethernet1/4         c      1799 ethernet1/4       209.59.29.254   54:e0:32:f3:2d:81 ethernet1/4         c      1659 vlan.10           209.59.31.137   00:00:0c:07:ac:0d ethernet1/1         c      1221 vlan.10           209.59.31.138   84:78:ac:55:d1:c1 ethernet1/1         c      1669 vlan.10           209.59.31.139   d8:67:d9:0f:05:41 ethernet1/2         c      1669 Which causes me to realize a thing, that may or may not be relevant. I was having a time getting the hypervisors to talk on the vlan set aside for the 'private' 10.x.x.x network, so put my first round of hosts in the 209.59.29.193/26 network, hanging off ethernet 1/4.  After this deployment is done, I said, I'd go back and figure out what the problem is. ... View more

output .. admin@tn-gateway-01# show deviceconfig system system {   ip-address 10.220.0.127;   netmask 255.255.255.0;   update-server updates.paloaltonetworks.com;   update-schedule {     threats {       recurring {         daily {           at 01:30;           action download-and-install;         }       }     }     wildfire {       recurring {         every-hour {           at 20;           action download-and-install;         }       }     }     global-protect-datafile {       recurring {         weekly {           action download-and-install;           at 03:00;           day-of-week sunday;         }       }     }     anti-virus {       recurring {         daily {           at 00:30;           action download-and-install;         }       }     }   }   timezone US/Central;   service {     disable-telnet yes;     disable-http yes;   }   hostname tn-gateway-01;   default-gateway 10.220.0.1;   dns-setting {     servers {       primary 209.59.29.221;     }   }   route {     service {       dns {         source {           address 209.59.31.140/29;           interface vlan.10;         }       }       email {         source {           address 209.59.31.140/29;           interface vlan.10;         }       }       ntp {         source {           address 209.59.31.140/29;           interface vlan.10;         }       }       paloalto-updates {         source {           address 209.59.31.140/29;           interface vlan.10;         }       }       url-updates {         source {           address 209.59.31.140/29;           interface vlan.10;         }       }       wildfire {         source {           address 209.59.31.140/29;           interface vlan.10;         }       }     }   }   ntp-server-1 209.118.204.201;   domain corp.cicayda.com;   login-banner "Who knocks on my castle door? "; } [edit] admin@tn-gateway-01# ... View more

Once I entered configure mode, deleted the syslog-certificate.  Then the commit ran from GUI, and I was able to delete the 'bad' certificate. Thanks! ... View more

It is not checked. ... View more

Okay .. admin@PA-200> delete deviceconfig system syslog-certificate Invalid syntax. admin@PA-200 ... View more

Nope - nothing there.  This is a new install, new infrastructure: I haven't pointed it at the syslog server yet. ... View more

Removed that value - and we're good. I believe, now, that when the client PC logs into the VPN _all_ it's traffic is going to the colocation rack and using their internet.  So I still need to set up the split tunnel per the above link.  And next up: the powers that be want to expand our use of the apps and services on the servers in that rack, so 'a client per machine' is now a legacy solution and I need to think about a dedicated VPN tunnel.  Joy! But I feel a lot better about this: thanks. ... View more

Apologies for the delay - I'm a one-man IT department right now. Access Routes: 209.49.29.29/32 ... View more

Yes, a good ideas, all around.  Because this unit is a loaner from the reseller until 'ours' ships (it arrived on my desk last night) we didn't sweat the management connection to my backend switch because 'it's only a week' and 'working well enough to get to the (hah) important part which is configuring the servers and the data crunching application that will live on them. There is always a proper order for doing things and one violates them at risk of perilous peril.  Don't be that guy. ... View more

Yup - a thing I wasn't aware of was the roll-back option.  We figured out the problem: essentially I Added a rule for access to RDP.  This didn't commit, because of a routing issue, but it worked so I let it be. Later added a second rule to show all traffic with 'deny'.  Because it seemed like a neat idea. Removed the RDP rule.  Hit 'Commit' ... Which  - I conjecture - then told the thing to deny-all to all traffic.  Whoops. ... View more