Exchange has been this way for a long time here’s me explaining this very problem with older versions of Exchange. If you create a ‘Group’, be that a Distribution Group, or a ‘Microsoft 365’ Group, the default setting is to NOT ALLOW mail from anyone outside your organisation. If you attempt to send mail to that group you will see errors like these;
Errors;
550 5.7.133 RESOLVER.RST.SenderNotAuthenticatedForGroup; authentication required; Delivery restriction check failed because the sender was not authenticated when sending to this group
550 5.7.133 RESOLVER.RST.SenderNotAuthenticatedForGroup; authentication required; Delivery restriction check failed because the sender not authenticated when sending to the group’
550 5.7.193 UnifiedGroupAgent; Delivery failed because the sender isn’t a group member or external senders aren’t permitted to send to this group.
Allow External Senders (On Premises & Hybrid Exchange)
If you have your own on premises Exchange server, this includes those of you that have migrated to Exchange online, but are in Hybrid Mode and are syncing your domain objects into Microsoft/Office 365 (Azure). Then you should change this setting in the on premises Exchange Admin Centre.
Recipients > Groups > Select the group in question > Edit > Delivery Management > Change to ‘Senders inside and outside of my organisation’ > Save.
Note: Remember in hybrid mode this will need to sync to Microsoft online, so apply the ‘cup of coffee rule’ before testing it.
Recipients > Groups > Select the group in question > Edit > Delivery Management > Change to ‘Senders inside and outside of my organisation’ > Save.
New Exchange Admin Center
Microsoft 365 Groups: Recipients > Groups > Microsoft 365 > ‘Double Click’ the group in question > Settings > Allow external senders to email this group > Save.
Distribution Groups: Recipients > Groups > Distribution List > ‘Double Click’ the group in question > Settings > Edit Delivery Management.
Allow messages from people inside and outside my organisation > Save changes.
Related Articles, References, Credits, or External Links
Quite a while ago I wrote the “Connecting to and managing Cisco firewalls” article, which is still pretty complete, but I’ve been asked on a few occasions, “How do I actually configure the firewall to allow remote administration via, SSH, or HTTPS/ASDM, or Telnet
If you have no network connection to the firewall, then you will need to connect via console cable (CLICK HERE).
Solution
Cisco ASA Allow SSH – Via Command Line
1. Log on to the firewall > Go to enable mode > Go to configure terminal mode.
[box]
User Access Verification
Password:*******
Type help or '?' for a list of available commands.
PetesASA> enable
Password: ********
PetesASA# configure terminal
PetesASA(config)#
[/box]
2. Now you can either allow access for one machine, or a whole network, the syntax is “ssh {ip address} {subnet mask} {interface that you will be connecting to}.
[box]
The following will just allow one external host (123.123.123.123).
PetesASA(config)# ssh 192.168.1.10 255.255.255.255 outsideThe following will just allow a whole internal network 192.168.1.1 to 254
PetesASA(config)# ssh 192.168.1.0 255.255.255.0 inside
[/box]
3. You will need to create a username and password for SSH access, then set SSH to use the LOCAL database to check of usernames and passwords, (unless you are using LDAP, RADIUS, TACACS, or Kerberos for authentication.)
4. By default the SSH session times out after 5 mins, I prefer to change this to 45 minutes.
[box]
PetesASA(config)# ssh timeout 45
[/box]
5. To encrypt the SSH access you need to have an RSA keypair on the firewall, (Note: this is generated from the firewall’s host name, and its domain name, if you ever change either, the keypair will break, and SSH access will cease until the keypair is re-created). To create a key issue a “crypto key generate rsa” command;
[box]
PetesASA(config)# crypto key generate rsa mod 2048
INFO: The name for the keys will be: <Default-RSA-Key>
Keypair generation process begin. Please wait...
PetesASA(config)#
[/box]
Note: I set the key size to 2048, this is considered good practice
7. Lastly, save the changes with a “write mem” command;
[box]
PetesASA# write mem
Building configuration...
Cryptochecksum: 79745c0a 509726e5 b2c66028 021fdc7d
424 bytes copied in 1.710 secs (7424 bytes/sec)
[OK]
PetesASA#
[/box]
Cisco ASA Allow SSH – Via ASDM (version shown 6.4(7))
1. Connect via ASDM > Navigate to Configuration > Device Management > Management Access > ASDM/HTTPS/Telnet/SSH > Add > Select SSH > Supply the IP and subnet > OK. (Note you can set both the timeout, and the SSH versions you will accept, on this page also). Note you still need to generate the RSA Key (See step 5 above, good luck finding that in the ASDM – see the following article).
Cisco ASA – Enable AAA for SSH (Local Database) ASDM version 6.4(7)
Cisco ASA – Add a User to the Local Database
Cisco ASA – Allow HTTPS/ASDM – Via Command Line
1. Log on to the firewall > Go to enable mode > Go to configure terminal mode.
[box]
User Access Verification
Password: *******
Type help or '?' for a list of available commands.
PetesASA> enable
Password: ********
PetesASA# configure terminal
PetesASA(config)#
[/box]
2. Now you can either allow access for one machine or a whole network, the syntax is “http {ip address} {subnet mask} {interface that it’s connected to}.
[box]
The following will just allow one host (192.168.1.10).
PetesASA(config)# http 192.168.1.10 255.255.255.255 inside
The following will just allow a whole network 192.168.1.1 to 254
PetesASA(config)# http 192.168.1.0 255.255.255.0 inside
[/box]
3. Unlike telnet and SSH, HTTPS/ADSM access is via the firewalls enable password (Unless you have enabled AAA logon). this password is set with the “enable password {password}” command. (Note: You will already have entered this password in step 1, only do this if you wish to change it).
[box]
PetesASA(config)# enable password PASSWORD123
[/box]
4. You need to make sure that HTTPS access is enabled with a “http server enable” command.
[box]
PetesASA(config)# http server enable
Note: if your port forwarding https on your firewall you will NOT be able to get access externally unless you put it on a different port (i.e.1234).
PetesASA(config)# http server enable 1234
[/box]
5. Lastly, save the changes with a “write mem” command.
[box]
PetesASA# write mem
Building configuration...
Cryptochecksum: 79745c0a 509726e5 b2c66028 021fdc7d
424 bytes copied in 1.710 secs (7424 bytes/sec)
[OK]
PetesASA#
OK, the title of this might raise an eyebrow, but if you have access to the ASDM and you want to grant access to another IP/Network them you might want to do this. Connect via ASDM > Navigate to Configuration > Device Management > Management Access > ASDM/HTTPS/Telnet/SSH > Add > Select ASDM/HTTPS > Supply the IP and subnet > OK. (Note: You can also enable and disable the http Server here and change its port number).
Cisco ASA Allow Telnet – Via Command Line
WARNING: Telenet is insecure, if possible don’t use it, (usernames and password are sent unencrypted.)
1. Log on to the firewall > Go to enable mode > Go to configure terminal mode.
[box]
User Access Verification
Password: *******
Type help or '?' for a list of available commands.
PetesASA> enable
Password: ********
PetesASA# configure terminal
PetesASA(config)#
[/box]
2. Now you can either allow access for one machine, or a whole network, the syntax is “telnet {ip address} {subnet mask} {interface that its connected to}.
[box]
The following will just allow one host (192.168.1.10).
PetesASA(config)# telnet 192.168.1.10 255.255.255.255 insideThe following will just allow a whole network 192.168.1.1 to 254
PetesASA(config)# telnet 192.168.1.0 255.255.255.0 inside
[/box]
3. To set the password you use the “passwd” command (yes that’s spelled correctly).
[box]
PetesASA(config)# passwd PASSWORD123
[/box]
4. By default the telnet session times out after 5 mins, I prefer to change this to 45 minutes.
[box]
PetesASA(config)# telnet timeout 45
[/box]
5. Lastly, save the changes with a “write mem” command.
[box]
PetesASA# write mem
Building configuration...
Cryptochecksum: 79745c0a 509726e5 b2c66028 021fdc7d
7424 bytes copied in 1.710 secs (7424 bytes/sec)
[OK]
PetesASA#
[/box]
Allow Telnet – Via ASDM (version shown 6.4(7))
1. Connect via ASDM > Navigate to Configuration > Device Management > Management Access > ASDM/HTTPS/Telnet/SSH > Add > Select Telnet > Supply the IP and subnet > OK. (Note you can set the timeout on this page also).
Related Articles, References, Credits, or External Links
Assuming you already have web management enabled, and you want to access it from the outside (the untrusted zone).
Solution
1. Log into the web console of the Juniper.
2. Navigate to Security > Zones/Screen > Select the ‘Untrust’ Zone > Edit > Host inbound traffic – Interface > Select the Outside interface > Under Interface services add in ‘http’ > OK.
3. Then to save the change click Action > Commit.
4. Test Externally.
Related Articles, References, Credits, or External Links
If you have one client that’s taking all your bandwidth, or a server that’s getting a lot of connections from external IP addresses, and that’s causing you performance problems, you can ‘throttle’ traffic from/to that client by ‘policing’ its traffic.
Solution
To demonstrate, I have a 30Mb connection at home, when I run a test on the download connection speed from my desktop PC this is what I get;
So I’m going to throttle traffic to that IP address (10.254.254.90), so that it can only use 1Mb of the connection.
1. Create an ACL for traffic to and from the IP address you want to throttle. (Note: If your firewall is running a version older than 8.3, and you are throttling an IP that has a public IP address, use its public IP address not its private one).
[box]
User Access Verification
Password:*******
Type help or ‘?’ for a list of available commands.
PetesASA> enable
Password: ********
PetesASA# configure terminal PetesASA(config)# access-list ACL-THROTTLE extended permit ip host 10.254.254.90 any
PetesASA(config)# access-list ACL-THROTTLE extended permit ip any host 10.254.254.90
[/box]
2. Now create a class-map that will match all traffic in that ACL, (so all traffic to and from 10.254.254.90).
[box]
PetesASA(config)# class-map CM-THROTTLE
PetesASA(config-cmap)# match access-list ACL-THROTTLE
PetesASA(config-cmap)# exit
[/box]
3. Then create a policy-map, that takes all traffic identified in your class map, and rate limits the traffic to 1000000 bps (1Mbps) with a ‘burst-rate’ of 2000bps.
4. Now apply that policy-map with a service policy. (Note: Generally you apply the policy to the interface closest to where the traffic is coming from, as this is an internal host, I’m applying it to the inside interface. If you were throttling traffic from outside it would be better to apply the service-policy to the outside interface).
I was in the PIX/ASA area at EE last night, and a poster asked if they could perform NAT on a couple of internal IP addresses to a spare public IP that they had. I had done this for a client some time last year when I performed and upgrade from 8.2. Anyone who has ever done a large upgrade on an ASA to the ‘new’ NAT system, will appreciate this is usually the area where the upgrade has a problem. So at the time ran through all the NAT/PAT rules on their firewall and worked out how to do the same with the new NAT code. That way if the upgrade failed I’d have all the new NAT rules per-written, (time spent on reconnaissance is seldom wasted!) Anyway when this question was asked I could not find the config I’d written so I ran up GNS3 and tested it.
Solution
In the example (above), I’m going to PAT both the internal servers to a public IP address of 123.123.123.124. The firewall already translates all other outgoing traffic to its external IP of 123.123.123.123. Note: I’m just translating two internal IP addresses, but you can translate as many internal hosts to this rule as you like.
1. Create a ‘group’ for your internal IP addresses;
3. Finally tie the two together with a NAT rule (that PAT’s the internal IP addresses to the spare public IP address). Remember this is a PAT not a NAT, hence the reason I use the ‘dynamic’ keyword below, and I don’t use ‘static’ as I would have done for a one-to-one NAT.
Note: The reason there’s a number ‘1’ in the command, is to put it at the top of the NAT processing order, so this rule will ‘fire’ before the global PAT rule I already have on the firewall.
4. At this point your internal servers may already have some NAT/PAT information cached on the firewall, before we test it let’s clear that out;
[box]Petes-ASA(config)# clear xlate[/box]
5. Now give it a test, you can check your public IP with the tool at the top of our ‘index page’, press the button that says ‘What’s is my IP‘. Once you are happy everything is working, save the changes on the firewall with a ‘write mem‘ command.
Related Articles, References, Credits, or External Links
