11-12-2018 04:54 PM
11-12-2018 05:24 PM
Are they sure this is correct? I would expect your gateway to be 80.80.169.17 and the PAN interface 80.80.169.18 since the interface subnet is a 80.80.169.16/30
11-12-2018 05:29 PM
Thanks. I won't be able to speak with them until the morning. It is 2:30 a.m. my time.
I will try your suggestions.
Thanks very much.
11-12-2018 06:24 PM
No luck. Can't find primary DNS. Set x.x.169.17 as gateway and the interface as x.x.x.18/30 (correct?). Next hop was set to x.x.169.17.
I have another router here from another ISP. When I get out through that router and ping the other ISP's addresses, I find that I can ping the 80.80.169.1 gateway but not x.x.x.16 and beyond. I cannot also ping the PDNS and SDNS.
Anything else I can do before I speak with them again? I would like to rule out the firewall if I can.
They claim that since they are providing connectivity to the port (lights flash), that the problem is with the firewall config. Since they changed the line and gave it a new ip, we could connect and use it up until today. But even still...every morning it needed to be reset by them. Today they mapped x.x.169.1 to the FW mac address.
Thanks.
11-12-2018 06:38 PM
I just set everything back to as it was in my first email.
I got in right away to our network. I have about 30 sec to 1 min before dns ages out. I was able to ping the x.x.169.1 gateway and both DNS servers. I could not ping x.x.x.16, etc.
do you know what is causing dns to age out?
Thanks.
11-12-2018 07:23 PM
As @pulukas mentioned 80.80.169.16/30 means that you can use only IPs 80.80.169.17 and 80.80.169.18.
One of them has to be your public IP and other ISP gateway.
You can't use 80.80.169.16/30 as interface IP as this is not usable IP.
Try both ways.
First assign 80.80.169.18/30 to your firewall and then try to ping ISP gw.
> ping source 80.80.169.18 host 80.80.169.17
And then check arp table
show arp ethernet1/1
(assuming that your wan interface is on ethernet1/1)
Do you see mac address behind 80.80.169.17?
If you see incomplete then try 80.80.169.17/30 on fw interface and ping 18.
If mac is there then can you ping 8.8.8.8
> ping source 80.80.169.18 host 8.8.8.8
If not then check if your routing is correct
>traceroute source 80.80.169.18 host 8.8.8.8
Is next hop 80.80.169.17?
11-14-2018 11:49 AM
Thank you to @Raido and @pulukas.
I am a volunteer math teacher overseas and have inherited the networking role. I have a distant background in the basics so bear with me as I get up to speed.
I was finally able to show the ISP guys the addressing fault issue. Now I have:
WAN IP: 80.80.169.16/25 (x.x.x.16 is mapped ... on the ISP side...to the PA 220 mac address)
GW: 80.80.169.1
PDNS: 80.80.160.8
SDN: 80.80.160.9
Static Route:
Default: 0.0.0.0/0
Next Hop: 80.80.169.1
NAT Policy
Original Packet
Source Zone: trust
Destintaion Zone: untrust
Destination Interface: any
Source and Destination address: any
Translated Packet
Translation Type: Dynamic IP and Port
Address Type: Interface Address
Interface: ethernet1/1
IP address: 80.80.169.16/25
ethernet1/1
Zone: untrust
IP: 80.80.169.16/25
ethernet1/3
Zone: trust
IP: 192.168.1.1/24
DHCP Server
ethernet1/3
IP Pool: 192.168.1.1/24
GW: 192.168.1.1
Subnet Mask: 255.255.255.0
PDNS: 80.80.160.8
SDNS: 80.80.160.9
I still cannot connect to the internet. I can do the following though...
flushdns, release ip, connect to the internet via PA220 . When I get in, I have about 2 minutes before I get kicked out.
During that time, I can tracert to both 8.8.8.8 and google.com, etc. I can ping the interface, the dns servers and the wan gw.
From CLI I can look at any/all session id's. They all end with a reason of n/a or aged out. Some are at INIT state, others ACTIVE.
When I could not get in at all and saw that the protocal in the session id was almost always udp (dns appl.), I uncreased that timer to 120 sec. That seems to allow me to play this game.
Can you help?
Thanks very much.
11-14-2018 12:03 PM
My PA-220 software version is 8.0.3.
There is an update in the 8.0.7 version that fixes a DNS failure issue due to BFD packets being associated with the destination port and not DNS packets.
Checking into this...thanks for any input.
11-14-2018 05:39 PM
What you have there now looks good. I assume there is also a security policy from trust to untrust allowing the internet access.
If you have a computer you can plug into the service port instead of the PAN and manually configure this information on the NIC.
WAN IP: 80.80.169.16/25 (x.x.x.16 is mapped ... on the ISP side...to the PA 220 mac address)
GW: 80.80.169.1
PDNS: 80.80.160.8
SDN: 80.80.160.9
Then test with your ISP. This removes the firewall from the path and the computer connected on this WAN address should have full internet access.
You mention the ISP is doing mac address locks. So to do this test they would have to release that and allow the address to be used by the computer.
This will confirm whether the issue is some configuration on the PAN or the service itself not allowing full access.
11-15-2018 12:03 PM
@j.anderson wrote:flushdns, release ip, connect to the internet via PA220 . When I get in, I have about 2 minutes before I get kicked out.
During that time, I can tracert to both 8.8.8.8 and google.com, etc. I can ping the interface, the dns servers and the wan gw.
If you can reach google DNS (8.8.8.8) and you suspect faulty ISP DNS. Why don't you try to put 8.8.8.8 as DNS for the PC behind the firewall?
For DNS you will always see the session ending reason - Aged out. that is because DNS is UDP and as such there is no way firewall knows when connection is ended or not. If it is TCP connection you have FIN or RST flags to mark the ending of a connection, firewall can see that and note in the logs that connection has ended normaly (with FIN) or is being reset by the client or server. UDP on other hand doesn't provide such functionality, so FW cannot tell if there are no other packets after the DNS reply. Thay is why FW is waiting for the DNS timeout timer to expire to remove the connection from the connection table. A healthy DNS connection will still be closed as aged-out, even if the reply was received right after the request.
For that reason the UDP timeout timer is relevantly slow number, if it is higher you can end up with lots of old connection filling the firewall table.
In my huble opinion there are quite a lot other scenarios that I don't see how increasing the UDP timeout can solve your issue. If you increase it to 120sec and you see improvment, that is not problem of the firewall, but you have HUUGE delay and even if you solve the dns you will have unusable slow connection.
At this point is quite clear for me that your ISP has some issues...If you are able to traceroute and ping 8.8.8.8 while you don't have internet connection, this clearly shows that you indeed have internet connectivity, but either the DNS you are using is having issues, or there is huge delay of the traffic.
11-20-2018 11:57 PM
Thanks again to all.
I am working in a country in Europe that is still quite underdeveloped and it has been difficult to work closely with the ISPs.
We have another ISP now working with us as the first one seems to share WAN addressing with its customers.
I am hoping that on Friday they will come onsite and we will hash this out until it works.
I think we are their only customer with a firewall in between their network and our LAN.
Thanks for staying with me and for all of the advice. I may put more of my configuration out in the next day or so just to make sure that there are no errors on my end. I am so grateful to you for your time and advice.
Best...
11-23-2018 06:04 AM
More information...
I will get all of the details of my configuration here in a bit but for now, this is the update:
Chronology:
1) Before new line was installed, connectivity was fine.
2) Because of a building addition, the fiber line had to be extended and they ended up giving us a new wan ip for the extended line. We were not informed of this until later.
3) The ip schema was faulty and many LIVE folks contributed. Thanks. That is correct now.
WAN GW: 80.80.169.1
WAN IP: 80.80.169.16/25
PDNS: 80.80.160.8
SDNS: 80.80.160.9
4) Before the new line was installed, we had just an ISP hardware fiber box with a fiber to ethernet converter.
5) Now we have an ISP Bridge, a Huawei HG8242H, sitting between our PA 220 and the fiber connection.
6) I am not able to view the configuration of the bridge...they won't let me in.
7) For about 2 weeks we had a connection with the new line and new definitions. However, we would have to call many mornings and have the line reset. Then we would be good for the day.
😎 About a week ago last Wednesday, we could not get out to the internet at all except for a few odd little windows where we can get into a website for 2 min or less and then we are kicked out. Those are very rare now...today I got glimpses of just 10-20 sec. But I went home on a Tuesday night with connectivity and came in on a Wednesday and we have been down since.
9) I have been suspicious of duplicate addressing of our WAN port. I disconnected the cable going into ethernet1/1 (address of 80.80.169.16) the other day, and from an outside network (hooked my computer up to my mobile phone hotspot) was still able to ping that address.
10) The ISP folks were here to day and they are going to check into this.
I will take screenshots of my configuration. If you can find any mistake on my part, I would be so grateful.
We are running the school now by connecting the LAN directly into another ISP's router and bypassing the PA 220. Not happy about this.
Thanks for your time.
-- Joan
11-23-2018 08:17 AM
From the CLI, I can ping the WAN IP but not the WAN GW.
11-23-2018 02:52 PM
Also:
From the CLI on the management interface, I can ping the WAN port but not the WAN GW (next hop).
Thank you.
Config. pictures:
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!
