ISP changed DSLAM now unable to connect to many web protocols using ADSL? - Page 2

kayasaman · ‎12-06-2010

Hi,

recently my ISP changed the DSLAM I am connected to from copper-trunk based over to fiber-trunk based and now I am unable to connect to the majority of websites and email services I use!

Even my Site-to-Site IPSEC VPN stopped working and upon debugging claims that malformed segmants are getting transacted.....

This is really weird and the support of the ISP is a disaster since it's the local telco and no other ISP to choose from.

I attempted to use Wireshark on ports udp, 53: tcp, 80: tcp, 143 for DNS, HTTP, and IMAP and it seems that many errors seem to be occuring for some reason.

I am using an 1801W router with version 3.0.33 firmware for the Alcatel based ADSL 20190 chipset which complies with ADSL2+ Annex A.

The downstream and upstream line usage dropped from 99% before to about 40% downstream now and round 60% for upstream which is a bit worrying.

Is there anything I can do on my end to get my line working like it was before?

Or at least does someone have some experience as to why this is occurring in order to help me understand?

I mean when I prompted the ISP about it, they claimed DNS; however the DNS entries come from a FreeBSD 8.0 based DNS server on the network which is connected directly to the "root" DNS servers as a "hinted root" zone. Basically checking the resolved IP addresses is exactly the same as another one of my networks in a different country.

What could be the issue here?

Many thanks!

Kaya

kayasaman · ‎12-07-2010

I just checked the ACL's last night and although corrent I seem to have summarized one but not the other!

This shouldn't affect things in my view, however if the IOS is picky as to what network and broadcast over IPSEC then I can understand why packet forwarding would account to an errornous state.

These are the ACL's in question:

Extended IP access list 101
    5 permit icmp 172.16.0.0 0.0.0.63 192.168.0.0 0.0.1.255 (7 matches)
    6 permit icmp 172.16.0.64 0.0.0.63 192.168.0.0 0.0.1.255 (67 matches)
    7 permit icmp 172.16.0.192 0.0.0.63 192.168.0.0 0.0.1.255
    10 permit ip 172.16.0.0 0.0.0.63 192.168.0.0 0.0.1.255 (37658 matches)
    20 permit ip 172.16.0.64 0.0.0.63 192.168.0.0 0.0.1.255 (6275 matches)
    30 permit ip 172.16.0.192 0.0.0.63 192.168.0.0 0.0.1.255 (39094 matches)
Extended IP access list 110
    10 deny ip 172.16.0.0 0.0.0.63 192.168.0.0 0.0.1.255 (18800 matches)
    20 deny ip 172.16.0.64 0.0.0.63 192.168.0.0 0.0.1.255 (3672 matches)
    30 deny ip 172.16.0.192 0.0.0.63 192.168.0.0 0.0.1.255 (19521 matches)
    40 permit ip 172.16.0.0 0.0.1.255 any (75821 matches)

On this machine I had 172.16.0.0/24 before which summarized 172.16.0.0/26 and the rest. Of course the geographically remote 857W on the other end was running a mirrored version of the above working ACL...... so I put it down to ACL miss-match.

Thanks Paolo :-)

Regards,

Kaya

paolo bevilacqua · ‎12-07-2010

Not that I understood much, but good that you solved, and good luck.

kayasaman · ‎12-07-2010

Thanks Paolo :-)

What I was trying to say is that this was the original ACL:

access-list 101 permit ip 172.16.0.0 0.0.0.127 192.168.0.0 0.0.1.255
access-list 101 permit ip 172.16.0.192 0.0.0.63 192.168.0.0 0.0.1.255
access-list 110 deny   ip 172.16.0.0 0.0.1.255 192.168.0.0 0.0.1.255
access-list 110 permit ip 172.16.0.0 0.0.1.255 any

But on my other router I had this:

Extended IP access list 101
    5 permit icmp 192.168.0.0 0.0.1.255 172.16.0.0 0.0.0.63 (8 matches)
    6 permit icmp 192.168.0.0 0.0.1.255 172.16.0.64 0.0.0.63 (54 matches)
    7 permit icmp 192.168.0.0 0.0.1.255 172.16.0.192 0.0.0.63 (22 matches)
    10 permit ip 192.168.0.0 0.0.1.255 172.16.0.0 0.0.0.63 (39266 matches)
    20 permit ip 192.168.0.0 0.0.1.255 172.16.0.64 0.0.0.63 (6659 matches)
    30 permit ip 192.168.0.0 0.0.1.255 172.16.0.192 0.0.0.63 (1906907 matches)
Extended IP access list 110
    10 deny ip 192.168.0.0 0.0.1.255 172.16.0.0 0.0.0.63 (1300749 matches)
    20 deny ip 192.168.0.0 0.0.1.255 172.16.0.64 0.0.0.63 (2887 matches)
    30 deny ip 192.168.0.0 0.0.1.255 172.16.0.192 0.0.0.63 (1365600 matches)
    40 permit ip 192.168.0.0 0.0.1.255 any (425703 matches)


Changing the first ACL entries in this post to my previous post rectified the situation.....


That's all I was trying to say.


Anyway.... :-)

paolo bevilacqua · ‎12-07-2010

Hi, it's not that IOS is picky, rather per ipsec standard, the prefix pairs must perfectly match for the SA to be built.

kayasaman · ‎12-07-2010

Oh!

Well, that explains it.

Thanks for that :-)