About vertical

Hi, sorry it was my fault. I had PBW rule on the wrong nic But in the end your hint with the app-override solved the problem. Thank you veeeeery much ... View more

Hi, thanks for your fast reply. It took me a step forward. I've set the app override rule for the port 4916 now: The app settings look look like this: The traffic log shows this now: Looks good for me but the traffic still doesnt reach the server on this port? btw: traffic on pptp port works fine and i can establish a connection on the same server. ... View more

Hi Numan, currently it is running on 5.0.6 since the support told me for another case, this would be the most stable and bugfree available. Here is the output from the log: Aug 13 10:36:51 Error: pan_pppoed_dp_connect(pan_pppoe_thread.c:261): pan_pppoed_setup_socket() failed Aug 13 10:36:51 Warning: pan_pppoe_setup_dp_conn(pan_pppoe_thread.c:344): Failed to connect to DP Aug 14 07:18:47 Error: pan_pppoe_recv_pkt(pan_pppoe_fsm.c:1321): [0x9fdb550/26][0] Drop PPP Sess pkt, sess_id received:1505 does not match pppoe_fsm sess id:0 Aug 14 07:18:47 Error: pan_pppoe_recv_pkt(pan_pppoe_fsm.c:1322): Aug 14 07:18:48 Error: pan_pppoe_recv_pkt(pan_pppoe_fsm.c:1321): [0x9fdb550/26][0] Drop PPP Sess pkt, sess_id received:1505 does not match pppoe_fsm sess id:0 Aug 14 07:18:48 Error: pan_pppoe_recv_pkt(pan_pppoe_fsm.c:1322): Aug 14 07:18:50 Error: pan_pppoe_recv_pkt(pan_pppoe_fsm.c:1321): [0x9fdb550/26][0] Drop PPP Sess pkt, sess_id received:1505 does not match pppoe_fsm sess id:0 Aug 14 07:18:50 Error: pan_pppoe_recv_pkt(pan_pppoe_fsm.c:1322): Aug 14 07:18:51 Error: pan_pppoe_fsm_run(pan_pppoe_fsm.c:1202): [0x9fdb550/26][0] Drop PPPoE PADT pkt, sess_id received:1505 does not match pppoe_fsm sess id:0 Aug 14 07:18:51 Error: pan_pppoe_fsm_run(pan_pppoe_fsm.c:1203): What is isn't as expected, that the timestamp is from yesterday morning. I could dial in, but had no real outgoing connection later on and also today in the timerange from 7:15 - 8:00. Also tried to dial in via my laptop and also experienced the same problem. I received an IP from an unsual Pool and had no connection to the ISP or beyond. I've checked on the ASA the little bit of information you get out of the config and the username is correct, but maybe the password was changed and no one in the company can remember so. I always thought, that if you try to dial in with wrong credentials, that you receive an error or so instead of receiving an IP which doesn't work correctly. ... View more

looks like the dial in account information i received is correct. gonna test it tomorrow via laptop...getting frustrating learning PAN ... View more

Hi guys, so I just finished the Test for my morning timeframe. The results are kinda disappointing and here is the summary: - pinging from given IP to GW IP didn't work, changed auth prot to chap, pap and auto with no difference - tested with disabled automatically create default route pointing to peer and also with enabled setting -> no difference - pinged the given IP from my smartphone -> ping successfully even with no access rule allowing the ping and no mgmt profile set on the IF -> this makes me believe, i've got the wrong account for dialing in - As Numan advised I've created the packet captures, nothing dropped. Flows and sessions have been created and no drop.pcap was made, only receive, firewall and transmit - as clarification, no I don't have a working WAN connection with the PAN. The pictures should illustrate, that NAT, routing and access rules are working as planned. So since everything is looking fine from the firewall angle I guess I have to get back to my boss, to get the correct information for dialing in or do you have any other conclusion? ... View more

- changed the PA authentication from auto to pap which the ASA uses prior to todays testing -> didn't help - it is a dynamic ip, but the pool doesn't change that much - yes it is correct the PAN receives an entirely different public ip than the public ips the asa gets assigned. ... View more

thanks for that ... View more

thanks guys, that was indeed the problem for those wondering why the traffic was dropped but not logged: you need to define a rule that matches a drop, the default deny rule does not log. ... View more

security rule: source zone: WAN any any any dest zone: LAN SBS_internal application and service: any NAT: rule 1: src zone: LAN src address SBS_internal dst zone: WAN static nat: 218.1.1.220 bi directional: no rule 2: src zone: WAN dst zone: WAN dst address 218.1.1.220 Dest NAT: SBS_internal all rules are on top, so nat+pat doesn't hit traffic from the server. pinged 8.8.8.8 from the server and it was sucessfully nat'ed to the expected public IP and replies came back in. however inbound connections are not logged for this public ip yep also filtered the logs for the specific ip or WAN as dst zone, but even without filters i didn't see the traffic ... View more

definitely what TMG does is not possibe with a PA and mikand's answer provides the only choices we have to migrate TMG. The company I'm working for has also a TMG and I've get to handle the migration coming soon. I've talked this issue through with an SE from PAN to a definite answer on this. ... View more