1.) OK, in this case you can of course just ignore the overload command!
And if that is active, a ping from the router itself to 8.8.8.8 for example is not successfull.
Yes, that is expectable cause, you did not define a source address with the ping command! If you do NOT do this, the router takes his local LAN IP as source and this IP is due to your static NAT statement NOT translated cause it only translates traffic from host 192.168.1.2 but not the local LAN IP. If you issue a ping 8.8.8.8 source <wan_ip>or<wan_interface> it will work fine even with the NAT statement! Always keep in mind what NAT is doing!! The Cisco does exactly what you tell him to do!!
1. Yes but I dont use the overload command, I use static NAT that translates one internal IP to the public WAN IP.
ip nat inside source static 192.168.1.2 <WANIP>
And if that is active, a ping from the router itself to 8.8.8.8 for example is not successfull. If I disable the static NAT, it is successful. Thats what I dont understand.
5. Here the same, as I wrote on 1. I use a static NAT like that:
ip nat inside source static 192.168.1.2 <WANIP>
and with that configuration, I get like 10-20 entries in the ip nat translations list. And under those entries are some whith ports that I didnt allow on the ZFW.
6. Okay perfect thank you
Thank you for your note, didnt know about that. I thought I have to put every interface which is on the internet side ot the internet zone. But good to know. Fixed that already.
So you say it is a normal behaviour that the echo reply will then be translated via nat?
No, of course not. Everything which is translated by NAT is explicitly defined in the ACL which is mapped to the overload command. I guess in your case its all 120?! (Not shown in config excerpt!)
ip nat inside source list 120 interface Dialer0 overload ! access-list 120 permit ip 192.168.101.0 0.0.0.255 any (only source IPs with 192.168.101.x are NATed!) ! dialer-list 1 protocol ip list 120
Due to the fact that outside Internet IPs are not matching the NAT ACL they were never tranlated. Other than that they come in on the ip nat outside interface, so the NAT acl will never get a match anyway, cause its related ONLY on the inside interface! The echo reply will therefore send with the WAN IP address (self) as source.
5.) Static NAT from an outbound or an inbound interface? So, a port forwarding (from outbound) or a static NAT from an inbound interface to a static IP on the outbound? Overload is PAT. Thats unfortunately unclear? 🤔 (Port forwarding setup for a ZFW can be seen here)
6.) Yes, that could be seen as well but with the ACL counters. show access-lists shows you all blocked packets. If you need more detailed info on this add the "log" parameter to the acl statements. But be carefull here. ACL logs are process switched (done in CPU) and hence logs should not be written from acls who block a wide range of packets which can overwhelm the CPU.
Important: You've made another severe configuration error in the above config!! The interface GigabitEthernet0/0/0 together with its corresponding 0.7 subinterface is only the physical interface to where the Dialer Interface is mapped. This interface carries NO IP address and is therefore only a physical L2 mapping with no IP traffic. Firewalls are of course explicitly used on Interfaces WITH IP addresses, cause a firewall is based on IP. So never ever set a ZFW zone on non IP Interfaces. This is obviously wrong and should be instantly removed!! The dialer is here the interface which participates in IP forwarding and holds the (WAN) zone!
1. I have tried that a few day ago, thats why you dont see icmp allowed in the lists. But with one difference, I entered permit icmp any any on internet to router and router to internet policy. I thought that should work as well, but it didnt. So you say it is a normal behaviour that the echo reply will then be translated via nat?
2. I thought I already tried that but I will try it again.
4. Got it. But what is the consequence of inspect? Will it see packets which are dangerous but are sent with a matched protocol?
5. I think you missunderstood my question. Yes that is clear, that source ports are always random. But I have a static NAT running and when I take a look at show ip nat translatios, I get entries which have a destination port, that I have not allowed in the firewall. Thats why I am asking if the nat translation is happening before the firewall is inspecting the traffic. Because then I dont have to worry about those entries. But if they should be dropped before the nat translation is happening, then something doesnt work with the FW, cause why would those entries be there then? You know what I mean?
6. I thought I tried everything in there but maybe I missed something. I thought there should be a possibility to see that for example the access-list ALLOWv4 dropped 100 packets and show me details about the packets like source and destination ip/port.
This statement is totally confusing. The Fritzbox-firewall coupling port is the UDM WAN interface which is, regarding to your description, 192.168.2.10. So does this mean you have 2 local LAN networks on your UDM or is one just the internal Wireguard adressing? Helpful for a focused troubleshooting here would be both, the WG server and client config file!
All further details and ToDos you'll find in the local Wireguard Tutorial!
1.) That is normal behaviour. You have mapped the ACL "ALLOWv4" to the policy-map "INTERNET_ROUTER_POLICY" which is responsable for the protocols which are allowed to pass the firewall from outside. (FROM internet TO the router) Your acl "ALLOWv4" only allows IPsec traffic from outside but missed having permit icmp any any echo configured to let ICMP echo requests pass as well. Btw. if you get a fix IP addresse you can make the "ALLOWv4" ACL a bit more stricter and define your static IPv4 as the target IP like: ip access-list extended ALLOWv4 20 permit udp any <wan_ip_address> eq isakmp 30 permit udp any <wan_ip_address> eq non500-isakmp 40 permit esp any <wan_ip_address> 50 permit icmp any <wan_ip_address> echo
2.) Try sh policy-map type inspect zone-pair sessions which shows all inspected endstations by ip and protocol and show policy-map type inspect zone-pair <zone_pair_name> for detailed protocol statistics.
3.) That is correct!
4.) Access lists define which IPs, ports etc. are allowed and match protocol defines the protocols in general which are allowed and will be deeper inspected. With match protocol you have to watch the sequence, cause deeper inspected protocols have to be placed before the shotgun commands match protocol tcp and match protocol udp at the end! These commands will inspect ALL not explicitly defined above UDP and TCP protocols. So it is mandatory to put them at the end of the list. If you like to inspect and pass only dedicated TCP protocols defined above you need to omit these shotgun commands in the match protocol sequence. Protocol and ACL class maps can of course be combined here.
5.) No, thats not true! The NAT overload function (in case you mean this?!) translates only IP addresses and not ports. As a professional networking specialist you know and should keep in mind that source ports are always random in TCP and UDP session by design. Only destination Ports are dedicated and dependent on the application.
6.) Always check the ZFW section in the Cisco tutorial for a proper setup! Unfortunately in German but a translator my help here otherwise just ask. If you need to do port forwarding with the ZFW firewall you'll find a dedicated English tutorial HERE.
I will post my running cisco config below. I have an external modem on my cisco router, which gets an fixed IP-Adress from the provider. I implemented a ZFW firewall and now I have a few questions.
1. When I allowed ICMP from Internet to self and self to internet, I can not ping the router from outside overall. And I can not ping from the router to 8.8.8.8 for example. If I disable NAT the router can ping 8.8.8.8. That is confusing for me, cause that means, that the router will send a ping to 8.8.8.8 and the response will then be translated from nat? Or why does it not work with nat?
2. I could not figure out how to check that the fw is working properly. There are a few show commands but they only show me how many packets are dropped or passed. I tried some log commands on the policy settings but cant access them. I search for a way to exactly see which packets are dropped, passed, inspected and so on.
3. In the section policy-map ... and class type inspect... I can set the parameter drop, inspect or pass. As I understand, the difference between inspect and pass is, that pass will only pass the packets from one zone to the other, while inspect will allow the retraffic as well without a policy on the other zone pair. Is that correct? So if I inspect for example port 1701 and PC A send a test packet with a dynamic source port 34500 for example, then the packet will be forwarded and the retraffic to the port 34500 is then also allowed?
4. What is the difference on class-map if i use it with a access-list or with the match protocol commands?
5. When I use the show ip nat translation command, I see many translations on random ports, is this normal? That would mean that NAT is translating incoming traffic first and then the firewall drops the traffic. Is that true?
6. Maybe you can give me an assessment to my configuration, that would be very helpful. Are there any other security settings I can do to secure my network?
version 17.2
service timestamps debug datetime msec
service timestamps log datetime msec
service password-encryption
service call-home
platform qfp utilization monitor load 80
platform punt-keepalive disable-kernel-core
!
hostname XXX
!
boot-start-marker
boot-end-marker
!
!
vrf definition Mgmt-intf
!
address-family ipv4
exit-address-family
!
address-family ipv6
exit-address-family
!
security authentication failure rate 3 log
security passwords min-length 7
enable secret 9 XXX
!
aaa new-model
aaa local authentication attempts max-fail 3
!
!
aaa authentication login default local
aaa authorization network default local
!
!
!
!
!
!
aaa session-id common
clock timezone CET 1 0
clock summer-time CEST recurring last Sun Mar 2:00 last Sun Oct 3:00
!
ip domain name XXX
!
!
!
login on-success log
!
!
!
!
!
!
!
subscriber templating
!
!
!
!
!
parameter-map type inspect global
log dropped-packets
multilink bundle-name authenticated
!
!
diagnostic bootup level minimal
!
spanning-tree extend system-id
!
redundancy
mode none
!
!
!
!
!
no cdp run
!
!
class-map type inspect match-any ALLOW_IN
match access-group name ALLOWv4
class-map type inspect match-any ROUTER_PROTOCOLS
match protocol tcp
match protocol udp
match protocol icmp
class-map type inspect match-any INTERNET_ALLOW
match access-group name ALLOWINTERNET
class-map type inspect match-any LOCAL_ALLOW
match access-group name ALLOWLOCAL
!
policy-map type inspect ROUTER_INTERNET_POLICY
description Traffic Router to Internet
class type inspect ROUTER_PROTOCOLS
inspect
class class-default
drop
policy-map type inspect INTERNET_ROUTER_POLICY
description Traffic Internet to Router
class type inspect ALLOW_IN
pass
class class-default
drop log
policy-map type inspect LOCAL_INTERNET_POLICY
description Traffic LOCAL to Internet
class type inspect LOCAL_ALLOW
pass
class class-default
drop
policy-map type inspect INTERNET_LOCAL_POLICY
class type inspect INTERNET_ALLOW
pass
class class-default
drop log
!
zone security LOCAL
zone security INTERNET
zone-pair security INTERNET_LOCAL source INTERNET destination LOCAL
service-policy type inspect INTERNET_LOCAL_POLICY
zone-pair security INTERNET_ROUTER source INTERNET destination self
service-policy type inspect INTERNET_ROUTER_POLICY
zone-pair security LOCAL_INTERNET source LOCAL destination INTERNET
service-policy type inspect LOCAL_INTERNET_POLICY
zone-pair security ROUTER_INTERNET source self destination INTERNET
service-policy type inspect ROUTER_INTERNET_POLICY
!
!
!
interface GigabitEthernet0/0/0
description Internet static IP
no ip address
zone-member security INTERNET
speed 1000
no negotiation auto
no cdp enable
!
interface GigabitEthernet0/0/0.7
description VLAN 7 tag for DSL
encapsulation dot1Q 7
zone-member security INTERNET
pppoe enable group global
pppoe-client dial-pool-number 1
!
interface GigabitEthernet0/0/1
description local LAN
ip address 192.168.1.1 255.255.255.0
ip nat inside
zone-member security LOCAL
ip tcp adjust-mss 1452
negotiation auto
!
interface GigabitEthernet0
vrf forwarding Mgmt-intf
no ip address
shutdown
negotiation auto
!
interface Dialer1
ip address negotiated
no ip redirects
no ip unreachables
no ip proxy-arp
ip nat outside
ip verify unicast reverse-path
zone-member security INTERNET
encapsulation ppp
dialer pool 1
dialer-group 1
ppp authentication pap callin
ppp pap sent-username XXX@t-online.de password 7 XXX
ppp ipcp dns request
ppp ipcp mask request
ppp ipcp route default
!
ip forward-protocol nd
no ip http server
no ip http secure-server
ip nat inside source static 192.168.1.2 XXX
!
!
ip access-list extended ALLOWINTERNET
10 permit udp any any eq 1701
20 permit udp any any eq isakmp
30 permit udp any any eq non500-isakmp
40 permit esp any any
50 permit ahp any any
ip access-list extended ALLOWLOCAL
10 permit udp any any eq 1701
20 permit udp any any eq isakmp
30 permit udp any any eq non500-isakmp
40 permit esp any any
50 permit ahp any any
60 permit tcp any any
70 permit udp any any
ip access-list extended ALLOWv4
20 permit udp any any eq isakmp
30 permit udp any any eq non500-isakmp
40 permit esp any any
ip access-list extended CLI_ACCESS
10 permit tcp 192.168.1.0 0.0.0.255 any eq 22
20 deny ip any any log-input
3 remark Config Access Router ACL
!
dialer-list 1 protocol ip list 120
!
!
!
!
!
!
control-plane
!
banner exec ^CSie sind verbunden mit VTY $(line) auf dem Router $(hostname)^C
!
line con 0
stopbits 1
line aux 0
stopbits 1
line vty 0 4
access-class CLI_ACCESS inexec-timeout 120 0
transport input ssh
!
I have set up the Wireguard server on my UDM Pro, on the client conf i changed the endpoint to the ddns name who is configured on the fritzboxbut I get on the client "handshake did not complete".
My Setup:
ISP -> FritzBox 7590 -> UDM Pro (double nat)
Fritzbox: 192.168.2.1
On the fritzbox wireguard port forwarding to udm pro (192.168.2.10)
Udm pro: 192.168.1.1
Firewall subnet 192.168.120.0/24
Firewall rules on udm pro Internet in/out/local on any:any
Did anyone have an Idee what else is to do that i got an Connection with my VPN client?
You should also move the uploaded image under "Article image" (3rd button after the "edit"). That places the nice image as the articel image and not uselessly at the end.
Nice tutorial but it would be much easier for all readers if you highlight the Linux commands either in boldface or use the code tags. The other bad thing is the useless and unnecessary masquerading inside the tunnel. This is an also unnecessary waste of performance if you tunnel internal ip networks over the GRE tunnel. Other than that in modern Debian based Linux distros the firewall default is nftables and not anymore the old depricated iptables. One other important thing readers should be aware of and which this tutorial correctly mentions is the fact that GRE is not encrypted. So in case the GRE tunnel is send over public networks its highly recommended to use a Stongswan setup with transport encryption. See for example other GRE tutorials HERE and HERE for transportation encryption with IPsec. Away from that...well done!
This guide will walk through the setup and configuration of a GRE tunnel between two Linux hosts. The two Linux hosts are running Ubuntu 22.04 LTS.
What is a GRE tunnel in networking? GRE (Generic Routing Encapsulation) tunnels encapsulate network packets inside new network packets. A virtual link is established between two hosts, allowing the hosts to communicate as if they were directly connected. The Cisco-developed tunneling protocol can encapsulate most protocol packet types.
Is a GRE tunnel encrypted?
Though a GRE tunnel functions similarly to a VPN, packets traveling inside a GRE tunnel are not encrypted but are instead encapsulated inside a GRE header. You must configure IPSec separately if you want to maintain data confidentiality.
How to set up and configure a GRE tunnel Setting up a GRE tunnel naturally requires work on both hosts. You will need to create a tunnel interface on each, set up firewall rules, and create routing tables. For clarity, we'll name one host "Host A" and the other "Host B".
GRE tunnel setup on Host A Enabling IP forwarding
The first step is to enable IP port forwarding on our host. Without this the GRE tunnel will not work. This is possible with a single command:
sysctl -w net.ipv4.ip_forward=1
Creating the GRE tunnel interface
Now we can create the GRE tunnel interface from Host A to Host B:
ip tunnel add gre1 mode gre remote <HOST_B_IP> local <HOST_A_IP> ttl 25
Naturally, you should replace <Host_B_IP> with the IP address of your target server and <Host_A_IP> with the IP address of the machine you are currently connected to.
Next, we need to assign an IP address to the GRE interface on our host:
ip addr add <HOST_A_PRIV_IP_GRE>/30 dev gre1
You should replace <HOST_A_PRIV_IP_GRE> with an unused private IP, for example:
ip addr add 10.0.0.1/30 dev gre1
Now it's a simple matter of activating the GRE interface with the following command:
ip link set dev gre1 up
Setting up a firewall rule for source NAT We'll now add a firewall rule to perform source NAT. This will translate the source IP address of packets leaving our GRE interface into public routable addresses:
Creating routing table rules for the GRE tunnel interface Finally, we can add a custom routing table for the GRE tunnel that will route traffic from the GRE tunnel's source IP through the GRE table:
echo'100 GRE' >> /etc/iproute2/rt_tables
ip rule add from <HOST_A_PRIV_IP_GRE>/32 table GRE
ip route add default via <HOST_B_PRIV_IP_GRE> table GRE
EXAMPLE:
echo'100 GRE' >> /etc/iproute2/rt_tables
ip rule add from 10.0.0.1/32 table GRE
ip route add default via 10.0.0.2 table GRE
GRE tunnel setup on Host B For host B, the setup is the same, except of course that we must use flip the IP addresses and use a different private IP.
Enabling IP forwarding
We can set up IP forwarding on Host B with the same command as Host A.
sysctl -w net.ipv4.ip_forward=1
Creating the GRE tunnel interface Now we can create the GRE tunnel interface from Host B to Host A:
ip tunnel add gre1 mode gre remote <HOST_A_IP> local <HOST_B_IP> ttl 225
You should replace <Host_A_IP> with the IP address of your first server and <Host_B_IP> with the IP address of the machine you are currently connected to.
Next, we need to assign an IP address to the GRE interface on our host:
ip addr add <HOST_B_PRIV_IP_GRE>/30 dev gre1
You should replace <HOST_B_PRIV_IP_GRE> with an unused private IP, for example:
ip addr add 10.0.0.2/30 dev gre1
Now it's a simple matter of activating the GRE interface with the following command:
ip link set dev gre1 up
Setting up a firewall rule for source NAT We'll now add a firewall rule to perform source NAT. This will translate the source IP address of packets leaving our GRE interface into public routable addresses:
Creating routing table rules for the GRE tunnel interface Finally, we can add a custom routing table for the GRE tunnel that will route traffic from the GRE tunnel's source IP through the GRE table:
echo'100 GRE' >> /etc/iproute2/rt_tables
ip rule add from <HOST_B_PRIV_IP_GRE>/32 table GRE
ip route add default via <HOST_A_PRIV_IP_GRE> table GRE
EXAMPLE:
echo'100 GRE' >> /etc/iproute2/rt_tables
ip rule add from 10.0.0.2/32 table GRE
ip route add default via 10.0.0.1 table GRE
That's it! Your GRE tunnel should now be working. Remember, do not send any sensitive data via the tunnel without first setting up IPSec.
Office 2016, Office 2019 Applications: Access 2016, Access 2019, Excel 2016, Excel 2019, OneNote 2016, Outlook 2016, Outlook 2019, PowerPoint 2016, PowerPoint 2019, Project 2016, Project 2019, Publisher 2016, Publisher 2019, Skype for Business 2016, Skype for Business 2019, Visio 2016, Visio 2019, Word 2016, Word 2019
Productivity Servers: Exchange Server 2016, Exchange Server 2019, Skype for Business Server 2015, Skype for Business Server 2019
What does end of support mean? All of the above applications and servers (including Office 2016, Office 2019) will reach the end of support (EOS) on October 14, 2025. After this end date, Microsoft will no longer provide security fixes, bug fixes, or technical support. Using products after end of support leaves your organization vulnerable to potential security threats, productivity losses, and compliance issues.
What we recommend We recommend migrating devices running end of support products to the cloud with Microsoft 365 E3 to stay continuously supported. Microsoft 365 E3 includes familiar Microsoft 365 apps—such as Word, Excel, PowerPoint, Outlook, Teams, and more—along with online services like SharePoint and Exchange.
Microsoft 365 E3 is a comprehensive solution that not only includes the familiar Microsoft 365 apps but also offers a range of additional capabilities:
Foundational Zero-Trust: Helps secure identities, devices, and applications against threats.
Streamlined Endpoint Management: Provides IT administrators with management tools and enhanced user experience for employees.
Productivity and collaboration: Promotes collaboration across your organization, fostering new ways of working.
Other options for disconnected environments We know there is not a “one-size-fits-all" approach to how to manage EOS. This is why we also offer other solutions to help with your unique needs:
For devices that need to remain disconnected or are not yet ready to move the cloud, we launched Office Long-Term Servicing Channel (LTSC). This version of Office was designed for devices that can’t accept feature updates or connect to the Internet. Note that Office LTSC 2021 will reach the end of support on October 13, 2026.
To continue running Exchange Server on-premises, the next version of Exchange Server will ship in H2 of 2025. We recommend customers move to Exchange Server 2019 now. The next version of Exchange Server will be released before Exchange Server 2019 (and Exchange Server 2016) reach end of life, and customers can do an in-place upgrade from Exchange Server 2019 to the next version.
Additional resources Below are some other steps you can take to begin preparing your organization for Office 2016 and Office 2019 end of support:
Read the upgrade guidance for an overview of how to move from Office 2016 or Office 2019 to Microsoft 365 Apps.
Consider engaging Microsoft FastTrack, a Microsoft support service for moving to Microsoft 365 E3.
Use the new Total Economic Impact™ of Microsoft 365 E3 study to build your case for reducing cost and complexity with Microsoft 365.
Use the Microsoft 365 ROI Calculator to estimate your ROI for moving to Microsoft 365 or ask your Microsoft representative to help you tailor your custom potential ROI of adopting Microsoft 365.
Please visit our Office End of Support Tech Community for more information and resources about the end of support for Office. Or fill out this form to get in touch with sales and have a specialist demonstrate how Microsoft 365 can benefit your organization.
Do I need NAT when I just want to make a vpn ipsec tunnel to a remote station?
No, in this case NAT is not needed of course.
and it is working.
Congrats! 👏👍
Now I will install a zone based FW and then I should be ready for the VPN implementation.
All steps for both functions you'll find in the above Cisco Tutorial including a client VPN with all onboard VPN clients (L2TP). If your VPN is a site2site VPN you'll find additional tutorials here and here.
I changed the configuration regarding your example configuration and it is working. Now I will install a zone based FW and then I should be ready for the VPN implementation.
But it is an ADSL link with 16Mbit/s donwload speed, not a VDSL link in case that makes a difference?
Nope, that does'nt matter. All modems are hybrid modems and work with both ADSL and VDSL. The Cisco only "sees" the PPPoE traffic which is plain Ethernet on his site.
For further investigations you can also activate the debugger with debug pppoe packets and debug pppoe events to watch the PPPoE control traffic with the provider DSLAM. That also shows you and verifies if the modem is working properly and passes PPPoE traffic from the router. Keep in mind that you need to issue a term mon command in case you are connected via Telnet or SSH and not directly on the serial console. Otherwise debug or console messages will not be forwarded to Telnet or SSH connections!
It is true, that I have a german Telekom link. I just wrote in english for more answers. But it is an ADSL link with 16Mbit/s donwload speed, not a VDSL link in case that makes a difference?
I saw on the zyxel webinterface, that I can tag the traffic so I will try that.
I will try out your recommended configuration changes and give a report.
Hello again, We contacted Nvidia again and found out that display mode is activated. To deactivate this we have to use a tool, unfortunately we also get an error “NO NVIDIA Display adapters found”.
That is not correct! Please take a look into the modems manual. Like all other modems on the market the Zyxel VMG3006 can do the mandatory VDSL tagging too! Under Network setting-> Broadband -> Add/Edit new WAN Interface" it can be set without an problems if you want the modem to do the VDSL VLAN tagging:
From the dialer port ppp user credentials it looks like its a European VDSL connection. You hopefully have on the radar that nearly every EU provider used a VLAN tagged VDSL connection?! In terms of the German T-Com its VLAN ID 7 which your port config is missing in case your external modem did NO tagging. With an external modem you have to first clarify if your modem is providing the VLAN 7 tag or if the router must do this in case the modem cannot provide the tag.
The other 2 important issues are the missing NAT (address translation to the Internet) and the correspondent dialer list and overload command as well as the missing MTU setting on the PPPoE port. The German T-Com (in case its a T-Com connection?!) did not support CHAP in the PPP authorisation so you can omit that. On top of thatl the PPP DNS and default route requests are missing so that the PPP link will fail. Also you can omit the IP related settings on the physiacl port. They all belong to the mapped Dialer interface only. So a bunch or configuration issues which prevents the PPPoE connection from working correctly. 🤔
Assuming this is a German T-Com connection and your modem is providing the mandatory VLAN 7 tag, a correct configured Dialer interface should look like this:
!
interface GigabitEthernet0/0/0
description Internet static IP
no ip address
negotiation auto
no cdp enable
pppoe enable group global
pppoe-client dial-pool-number 1
!
interface Dialer0
description VDSL PPPoE Internet Interface
ip address negotiated
mtu 1492
no ip redirects
no ip unreachables
no ip proxy-arp
ip verify unicast reverse-path
ip nat outside
encapsulation ppp
dialer pool 1
ppp authentication pap callin
ppp pap sent-username 001234567890123456780001@t-online.de password 1234567
ppp ipcp dns request
ppp ipcp mask request
ppp ipcp route default
!
interface GigabitEthernet0/0/1
description Local LAN
ip address 192.168.1.254 255.255.255.0
ip nat inside
ip tcp adjust-mss 1452
!
ip nat inside source list 120 interface Dialer0 overload
!
dialer-list 1 protocol ip list 120
!
access-list 120 permit ip 192.168.1.0 0.0.0.255 any
In case your external modem does no VLAN tagging for the PPPoE connection itself you need the router to do this. This requires some change at the physical interface to work with an 802.1q tagged VLAN subnet.
interface GigabitEthernet0/0/0
description Internet static IP
no ip address
no cdp enable
!
interface GigabitEthernet0/0/0.7
description VDSL Internet Verbindung - VLAN 7 tagged
encapsulation dot1Q 7
pppoe enable group global
pppoe-client dial-pool-number 1
!
Additional important points which should be corrected in your config!:
With ppp ipcp route default the default route is automatically requested from the provider and the static route ip route 0.0.0.0 0.0.0.0 Dialer1 is not necessary anymore and should be deleted form the config. For PPP that is a much better option to propagate the default route. ppp ipcp dns request sets the PPPoE provided DNS server.
The "20 deny ip any any" statement in the ACL 120 is default and can be omitted
It is higly insecure to let the HTTP server active on the router which is exposed to the internet. Due to the recent security breach CVE-2023-20198 which makes unpatched Cisco routers vulnerable by HTTP the HTTP and HTTPS servers should always be disabled with no!!
You should activate service password-encryption and should never use unencrypted passwords. Always use scrypt style passwords. See HERE for further details!
Take a look at the local Cisco router tutorial which describes all the steps in detail. Unfortunately in German, but a translator may help here.
I have a cisco ISR4321 router with OS 17.02.01r and a zyxel VMG3006-D70A modem.
I want to use the modem on a ADSL 16Mbit link with a fixed IPv4 address from ISP. The modem is in modem mode by default. That means, that all packets that come to the DSL port will be forwarded to port 2-4. The modem is connected to the dsl port and the status on the webinterface of the modem is "connected", I can also see the up-/download speed. Then I connected the cisco router to the modem port 4. The port on the router is port GigabitEthernet 0/0/0. With the show pppoe commands and so on I see that it is not up and running. Even the IP-Address is not assigned automatically. (Should I see that?)
Attached you can find my router configuration, but I cant figure out what I made wrong. I had a template configuration from an old colleague who is not in our company anymore, from which I tried to configure this setup.
It would be very helpfull if someone can help or assist here. If I shall provide some logs etc. pls tell me.
Thank you very much and best regards
gleixnerd
version 17.2
service timestamps debug datetime msec
service timestamps log datetime msec
service call-home
platform qfp utilization monitor load 80
platform punt-keepalive disable-kernel-core
!
hostname static3tsg-rt01
!
boot-start-marker
boot-end-marker
!
!
vrf definition Mgmt-intf
!
address-family ipv4
exit-address-family
!
address-family ipv6
exit-address-family
!
enable secret 9 XXX
!
aaa new-model
!
!
!
!
!
!
!
!
aaa session-id common
!
ip domain name XXX
!
!
!
login on-success log
!
!
!
!
!
!
!
subscriber templating
!
!
!
!
multilink bundle-name authenticated
!
!
!
crypto pki trustpoint TP-self-signed-2440242732
enrollment selfsigned
subject-name cn=IOS-Self-Signed-Certificate-2440242732
revocation-check none
rsakeypair TP-self-signed-2440242732
!
crypto pki trustpoint SLA-TrustPoint
enrollment pkcs12
revocation-check crl
!
!
!
no license feature hseck9
license udi pid ISR4321/K9 sn FDO261629VN
license boot level securityk9
memory free low-watermark processor 69596
!
diagnostic bootup level minimal
!
spanning-tree extend system-id
!
username admin privilege 15 password 0 XXX
!
redundancy
mode none
!
!
!
!
!
!
interface GigabitEthernet0/0/0
description Internet static IP
no ip address
no ip proxy-arp
negotiation auto
no cdp enable
pppoe enable group global
pppoe-client dial-pool-number 1
ip virtual-reassembly
!
interface GigabitEthernet0/0/1
ip address 192.168.1.1 255.255.255.0
negotiation auto
!
interface GigabitEthernet0
vrf forwarding Mgmt-intf
no ip address
shutdown
negotiation auto
!
interface Dialer1
ip address negotiated
no ip proxy-arp
encapsulation ppp
dialer pool 1
dialer-group 1
ppp authentication chap pap callin
ppp chap hostname XXX@t-online.de
ppp chap password 0 XXX
ppp pap sent-username XXX@t-online.de password 0 XXX
!
ip forward-protocol nd
ip http server
ip http authentication local
ip http secure-server
ip tftp source-interface GigabitEthernet0
ip route 0.0.0.0 0.0.0.0 Dialer1
!
!
!
ip access-list extended 120
10 permit ip 192.168.1.0 0.0.0.255 any
20 deny ip any any
dialer-list 1 protocol ip permit
!
!
!
!
!
control-plane
!
!
line con 0
stopbits 1
line aux 0
stopbits 1
line vty 0 4
access-class 120 inexec-timeout 120 0
transport input telnet ssh
!
